[GH-ISSUE #7638] [Bug] Update failure remediation inserts a second terminal period #4562

Closed
opened 2026-10-31 00:50:48 +00:00 by bsakaguchi · 0 comments
Owner

Originally created by @coygeek on GitHub (Oct 28, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/7638

Before submitting

  • I searched the open and closed issues for a related report.
  • I removed credentials, tokens, private paths, and sensitive target data.

Area

Setup, packaging, or upgrade

Observed behavior

Running node scripts/rea.mjs update --json with a silent failing package-manager fixture returned a remediation sentence containing 97.. Retry. Returning JSON null from the release lookup instead produced array.. Check. Both are consecutive periods at the boundary between the diagnostic and the recovery advice.

Both commands correctly exited 1 with status: "failed", reason: "version-check" and latestVersion: null. The defect is the extra punctuation in the user-visible string.

Reproduction

  1. Use the built baseline checkout and put Node.js 24.22.1 first on PATH. No dependency installation or network access is needed for this reproduction.
  2. Run the following shell block from the checkout root. It creates recording fixtures for npm, npx and bun, isolates HOME/XDG/TMPDIR, exercises both variants twice, prints the invocation log, and removes the fixture directory on exit. Run without shell errexit because exit 1 is expected from each update command.
node_dir=$(dirname "$(command -v node)")
verify_root=$(mktemp -d)
trap 'rm -rf "$verify_root"' EXIT
mkdir -p "$verify_root/bin" "$verify_root/home"
cat > "$verify_root/bin/npm" <<'FIXTURE'
#!/bin/sh
printf '%s' "${0##*/}" >> "$VERIFY_CALLS"
for arg in "$@"; do printf ' <%s>' "$arg" >> "$VERIFY_CALLS"; done
printf '\n' >> "$VERIFY_CALLS"
if [ "$VERIFY_MODE" = null ] && [ "${0##*/}" = npm ] && [ "$1" = view ]; then
  printf 'null\n'
  exit 0
fi
exit 97
FIXTURE
cp "$verify_root/bin/npm" "$verify_root/bin/npx"
cp "$verify_root/bin/npm" "$verify_root/bin/bun"
chmod +x "$verify_root/bin/"*
for verify_mode in silent silent null null; do
  env -i PATH="$verify_root/bin:$node_dir:/usr/bin:/bin" \
    HOME="$verify_root/home" TMPDIR="$verify_root/home" \
    XDG_CONFIG_HOME="$verify_root/home/config" \
    XDG_CACHE_HOME="$verify_root/home/cache" \
    XDG_DATA_HOME="$verify_root/home/data" \
    XDG_STATE_HOME="$verify_root/home/state" \
    VERIFY_CALLS="$verify_root/calls.log" VERIFY_MODE="$verify_mode" \
    node scripts/rea.mjs update --json
  verify_exit=$?
  printf '%s exit=%s\n' "$verify_mode" "$verify_exit"
done
cat "$verify_root/calls.log"
  1. Inspect the four JSON results and the log. Each silent result contains Process exited with code 97.. Retry; each null result contains single-element version array.. Check. All four update invocations exit 1. The log contains only one npm root probe and one npm view lookup per invocation, with no install command.

The shell block reproduced both variants twice during verification. An independent subprocess replay also reproduced each variant twice. Fixture allocation during verification used a designated disposable scratch parent; all fixture contents were deleted afterward.

Expected behavior

The remediation should retain the diagnostic and recovery advice with one terminal period between the sentences. Rejecting a nonzero lookup or JSON null is correct; the expected change concerns only the repeated punctuation.

This is an ordinary prose-composition expectation, not a documented guarantee about exact message bytes. Source evidence below shows that the diagnostic producers supply complete sentences and that other REA remediation composers avoid duplicating their terminal punctuation.

Impact and scope

P3 wording defect in the public remediation value on the two exercised release-lookup failure paths. Failure status and the underlying diagnostic remain correct. The recording fixtures showed no installation attempt, and no real package manager or registry was used.

The extra period does not require recovery to interpret the result; users can read the diagnostic and guidance as printed. Actual incidence with real npm output, other platforms, human-mode output, and other updater failure paths was not measured.

REA version

Exact node scripts/rea.mjs --version stdout:

6.8.0

Source baseline: 65f1c447344a423fa2785847dbcea1e9a9e2454a.

Runtime and platform

Node.js v24.22.1; macOS 27.0.1; arm64. npm, npx and bun were locally authored recording fixtures, not real package-manager installations.

Target and artifact context

A built source checkout with an isolated caller environment and package-manager fixtures. No analysis target or provider was involved.

Interface

CLI

Earliest failure stage

Transport or result projection

Relevant output or evidence

The silent fixture produced this exact stdout JSON, exit 1 and empty stderr:

{"status":"failed","currentVersion":"6.8.0","latestVersion":null,"reason":"version-check","remediation":"REA could not resolve the latest release: Process exited with code 97.. Retry rea update when registry access is available."}

The null fixture produced this exact stdout JSON, exit 1 and empty stderr:

{"status":"failed","currentVersion":"6.8.0","latestVersion":null,"reason":"version-check","remediation":"REA could not resolve the latest release: Invalid npm release metadata: expected a version string or a single-element version array.. Check the npm release metadata, then rerun rea update."}

The recording log repeated only these two entries for each invocation:

npm <root> <--global>
npm <view> <--global> <rea-agents> <dist-tags.latest> <--json> <--fetch-retries=0> <--fetch-timeout=10000>

Source locators at the baseline:

  • src/cli/setupCommands.ts:183-204 connects the supported update command to the system host and update workflow.
  • src/application/UpdateCommandRunner.ts:169-177 supplies a period-terminated diagnostic for a silent nonzero exit.
  • src/application/UpdateRuntime.ts:143-144 defines the period-terminated invalid-metadata diagnostic; :194-205 classifies the lookup result.
  • src/application/Update.ts:116-131 adds a period after the diagnostic in both affected remediation branches; :179-190 returns the version-check failure before installation.
  • src/application/UpdateRuntime.release.test.ts:28-39 and :51-60 pin the invalid-metadata detail including its single terminal period. src/application/Update.test.ts:242-262 and :278-299 check remediation substrings using details without terminal punctuation; they do not pin the doubled-period result. No such final-string test was found in the repository search. These tests were inspected, not executed for this verification.
  • src/pcap/PcapConfiguration.ts:64 and src/native/NativePlistSource.ts:118 provide existing examples of avoiding an additional terminal period while composing user-facing prose.

Typed outcome or recovery expected

Keep the existing failed/version-check result and diagnostic. Compose its remediation without introducing the second terminal period.

Analysis or suspected cause

Source-derived: the diagnostic producer and remediation composer both supply the same sentence terminator. The two strings join unchanged, producing the observed pair of periods. The parser test deliberately preserves one period on the detail; it does not establish that the composer should add another.

Additional context

Read-only duplicate searches covered open and closed issues, all PR states, issue comments, and relevant PR discussions/review comments using doubled-period, double-period, trailing-period, punctuation/remediation and release-lookup wording.

Issue #7597 concerns registry-retry advice for local Bun startup failures; correcting that advice does not resolve this punctuation defect. Issue #1123 and merged PR #1138 concern accepting npm 12 metadata and distinguishing metadata errors from failed registry commands. The merged diff introduces the complete invalid-metadata sentence and the affected composer, but does not report or claim to repair doubled punctuation. Related output-collection, Bun-support and ownership records (#4888, #4897, #4894, #1735 and #5061) cover different outcomes. No covering report or punctuation fix was found; no known-good-version regression is claimed.

Triage assessment

  • Impact level: P3
  • Assessment status: supported
  • Impact basis: Both controlled CLI failure paths produced malformed punctuation while preserving the failed outcome, actual diagnostic and absence of installation.
  • Workaround status: available
  • Workaround basis: The diagnostic and next-step text remain readable as printed; ignoring the duplicated period preserves the information needed to interpret the result.
Originally created by @coygeek on GitHub (Oct 28, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7638 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Setup, packaging, or upgrade ### Observed behavior Running `node scripts/rea.mjs update --json` with a silent failing package-manager fixture returned a remediation sentence containing `97.. Retry`. Returning JSON `null` from the release lookup instead produced `array.. Check`. Both are consecutive periods at the boundary between the diagnostic and the recovery advice. Both commands correctly exited 1 with `status: "failed"`, `reason: "version-check"` and `latestVersion: null`. The defect is the extra punctuation in the user-visible string. ### Reproduction 1. Use the built baseline checkout and put Node.js 24.22.1 first on PATH. No dependency installation or network access is needed for this reproduction. 2. Run the following shell block from the checkout root. It creates recording fixtures for npm, npx and bun, isolates HOME/XDG/TMPDIR, exercises both variants twice, prints the invocation log, and removes the fixture directory on exit. Run without shell errexit because exit 1 is expected from each update command. ```sh node_dir=$(dirname "$(command -v node)") verify_root=$(mktemp -d) trap 'rm -rf "$verify_root"' EXIT mkdir -p "$verify_root/bin" "$verify_root/home" cat > "$verify_root/bin/npm" <<'FIXTURE' #!/bin/sh printf '%s' "${0##*/}" >> "$VERIFY_CALLS" for arg in "$@"; do printf ' <%s>' "$arg" >> "$VERIFY_CALLS"; done printf '\n' >> "$VERIFY_CALLS" if [ "$VERIFY_MODE" = null ] && [ "${0##*/}" = npm ] && [ "$1" = view ]; then printf 'null\n' exit 0 fi exit 97 FIXTURE cp "$verify_root/bin/npm" "$verify_root/bin/npx" cp "$verify_root/bin/npm" "$verify_root/bin/bun" chmod +x "$verify_root/bin/"* for verify_mode in silent silent null null; do env -i PATH="$verify_root/bin:$node_dir:/usr/bin:/bin" \ HOME="$verify_root/home" TMPDIR="$verify_root/home" \ XDG_CONFIG_HOME="$verify_root/home/config" \ XDG_CACHE_HOME="$verify_root/home/cache" \ XDG_DATA_HOME="$verify_root/home/data" \ XDG_STATE_HOME="$verify_root/home/state" \ VERIFY_CALLS="$verify_root/calls.log" VERIFY_MODE="$verify_mode" \ node scripts/rea.mjs update --json verify_exit=$? printf '%s exit=%s\n' "$verify_mode" "$verify_exit" done cat "$verify_root/calls.log" ``` 3. Inspect the four JSON results and the log. Each `silent` result contains `Process exited with code 97.. Retry`; each `null` result contains `single-element version array.. Check`. All four update invocations exit 1. The log contains only one npm root probe and one npm view lookup per invocation, with no install command. The shell block reproduced both variants twice during verification. An independent subprocess replay also reproduced each variant twice. Fixture allocation during verification used a designated disposable scratch parent; all fixture contents were deleted afterward. ### Expected behavior The remediation should retain the diagnostic and recovery advice with one terminal period between the sentences. Rejecting a nonzero lookup or JSON `null` is correct; the expected change concerns only the repeated punctuation. This is an ordinary prose-composition expectation, not a documented guarantee about exact message bytes. Source evidence below shows that the diagnostic producers supply complete sentences and that other REA remediation composers avoid duplicating their terminal punctuation. ### Impact and scope P3 wording defect in the public remediation value on the two exercised release-lookup failure paths. Failure status and the underlying diagnostic remain correct. The recording fixtures showed no installation attempt, and no real package manager or registry was used. The extra period does not require recovery to interpret the result; users can read the diagnostic and guidance as printed. Actual incidence with real npm output, other platforms, human-mode output, and other updater failure paths was not measured. ### REA version Exact `node scripts/rea.mjs --version` stdout: ```text 6.8.0 ``` Source baseline: `65f1c447344a423fa2785847dbcea1e9a9e2454a`. ### Runtime and platform Node.js `v24.22.1`; macOS `27.0.1`; `arm64`. npm, npx and bun were locally authored recording fixtures, not real package-manager installations. ### Target and artifact context A built source checkout with an isolated caller environment and package-manager fixtures. No analysis target or provider was involved. ### Interface CLI ### Earliest failure stage Transport or result projection ### Relevant output or evidence The silent fixture produced this exact stdout JSON, exit 1 and empty stderr: ```json {"status":"failed","currentVersion":"6.8.0","latestVersion":null,"reason":"version-check","remediation":"REA could not resolve the latest release: Process exited with code 97.. Retry rea update when registry access is available."} ``` The null fixture produced this exact stdout JSON, exit 1 and empty stderr: ```json {"status":"failed","currentVersion":"6.8.0","latestVersion":null,"reason":"version-check","remediation":"REA could not resolve the latest release: Invalid npm release metadata: expected a version string or a single-element version array.. Check the npm release metadata, then rerun rea update."} ``` The recording log repeated only these two entries for each invocation: ```text npm <root> <--global> npm <view> <--global> <rea-agents> <dist-tags.latest> <--json> <--fetch-retries=0> <--fetch-timeout=10000> ``` Source locators at the baseline: - `src/cli/setupCommands.ts:183-204` connects the supported update command to the system host and update workflow. - `src/application/UpdateCommandRunner.ts:169-177` supplies a period-terminated diagnostic for a silent nonzero exit. - `src/application/UpdateRuntime.ts:143-144` defines the period-terminated invalid-metadata diagnostic; `:194-205` classifies the lookup result. - `src/application/Update.ts:116-131` adds a period after the diagnostic in both affected remediation branches; `:179-190` returns the version-check failure before installation. - `src/application/UpdateRuntime.release.test.ts:28-39` and `:51-60` pin the invalid-metadata detail including its single terminal period. `src/application/Update.test.ts:242-262` and `:278-299` check remediation substrings using details without terminal punctuation; they do not pin the doubled-period result. No such final-string test was found in the repository search. These tests were inspected, not executed for this verification. - `src/pcap/PcapConfiguration.ts:64` and `src/native/NativePlistSource.ts:118` provide existing examples of avoiding an additional terminal period while composing user-facing prose. ### Typed outcome or recovery expected Keep the existing failed/version-check result and diagnostic. Compose its remediation without introducing the second terminal period. ### Analysis or suspected cause Source-derived: the diagnostic producer and remediation composer both supply the same sentence terminator. The two strings join unchanged, producing the observed pair of periods. The parser test deliberately preserves one period on the detail; it does not establish that the composer should add another. ### Additional context Read-only duplicate searches covered open and closed issues, all PR states, issue comments, and relevant PR discussions/review comments using doubled-period, double-period, trailing-period, punctuation/remediation and release-lookup wording. [Issue #7597](https://github.com/morluto/rea/issues/7597) concerns registry-retry advice for local Bun startup failures; correcting that advice does not resolve this punctuation defect. [Issue #1123](https://github.com/morluto/rea/issues/1123) and merged [PR #1138](https://github.com/morluto/rea/pull/1138) concern accepting npm 12 metadata and distinguishing metadata errors from failed registry commands. The merged diff introduces the complete invalid-metadata sentence and the affected composer, but does not report or claim to repair doubled punctuation. Related output-collection, Bun-support and ownership records (#4888, #4897, #4894, #1735 and #5061) cover different outcomes. No covering report or punctuation fix was found; no known-good-version regression is claimed. ## Triage assessment - Impact level: P3 - Assessment status: supported - Impact basis: Both controlled CLI failure paths produced malformed punctuation while preserving the failed outcome, actual diagnostic and absence of installation. - Workaround status: available - Workaround basis: The diagnostic and next-step text remain readable as printed; ignoring the duplicated period preserves the information needed to interpret the result.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#4562
No description provided.