morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #7597] [Bug] Bun startup failures receive registry-retry recovery advice #4528

New issue

Closed

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

bsakaguchi commented

2026-10-31 00:50:31 +00:00

Owner

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

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

For an installation recognized as Bun-managed, node scripts/rea.mjs update --json advises retrying when registry access becomes available if the local bun --version command fails. A launcher that prints fixture: bun runtime cannot start and exits 7 produces:

{"status":"failed","currentVersion":"6.8.0","latestVersion":null,"reason":"version-check","remediation":"REA could not resolve the latest release: fixture: bun runtime cannot start. Retry rea update when registry access is available."}

The updater exits 1. Removing the Bun executable produces the same registry advice, with spawn bun ENOENT as the embedded error. In both cases the failure occurs before a release-metadata command. The subprocess error is retained, but the recommended recovery concerns a different cause.

Reproduction

Each failure variant reproduced twice on the baseline: once with an independent fixture runner and once with the shell fixture below. The fixture commands cannot contact a registry or install a package.

Start in the built baseline checkout, with Node.js 24.22.1 first on PATH. Create a disposable fixture directory and arrange automatic cleanup:

verify_root=$(mktemp -d)
trap 'rm -rf "$verify_root"' EXIT
mkdir -p "$verify_root/bin" "$verify_root/home" "$verify_root/global/node_modules"
ln -s "$PWD" "$verify_root/global/node_modules/rea-agents"
ln -s "$(command -v node)" "$verify_root/bin/node"
printf '{"name":"fixture-global"}\n' > "$verify_root/global/package.json"

Supply recording, offline package-manager fixtures:

cat > "$verify_root/bin/bun" <<'BUN'
#!/bin/sh
printf 'bun %s\n' "$*" >> "$VERIFY_CALLS"
echo 'fixture: bun runtime cannot start' >&2
exit 7
BUN
cat > "$verify_root/bin/npm" <<'NPM'
#!/bin/sh
printf 'npm %s\n' "$*" >> "$VERIFY_CALLS"
echo 'unexpected npm call' >&2
exit 93
NPM
chmod +x "$verify_root/bin/bun" "$verify_root/bin/npm"

Exercise a failing launcher and then a missing launcher with isolated HOME/XDG settings and restricted PATH. Use a shell without set -e so the expected exit 1 does not interrupt the second variant:

for verify_mode in failing missing; do
  [ "$verify_mode" != missing ] || rm "$verify_root/bin/bun"
  : > "$verify_root/calls.log"
  env -i PATH="$verify_root/bin:/usr/bin:/bin" \
    HOME="$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" \
    BUN_INSTALL_GLOBAL_DIR="$verify_root/global" \
    VERIFY_CALLS="$verify_root/calls.log" \
    node scripts/rea.mjs update --json
  verify_exit=$?
  printf '%s exit=%s\n' "$verify_mode" "$verify_exit"
  cat "$verify_root/calls.log"
done

Both commands exit 1 and recommend waiting for registry access. The first log contains only bun --version; the second is empty. Neither run invokes npm, a metadata lookup, or an installer. The fixture allocation during verification used a designated scratch parent; its contents were otherwise as shown and were deleted afterward.

Expected behavior

A local Bun executable failure should produce Bun-specific recovery guidance, such as making Bun available on PATH or repairing its launcher, while preserving the actual subprocess error.

The installation guide documents Bun 1.2.17 as the updater minimum and promises manual Bun recovery when its version is old or unparseable. It does not explicitly prescribe missing-executable wording. The repository's failure-model invariant also requires meaningful failure reasons. Together with the fact that metadata lookup has not started, these support identifying the local Bun failure rather than recommending recovery of registry access. Exact source references are in Evidence below.

The failed status, nonzero exit, and public reason: "version-check" can remain unchanged.

Impact and scope

The verified impact is misleading recovery wording for a Bun-owned installation whose version probe cannot start or exits unsuccessfully. The updater correctly fails and retains the Bun error. No package installation was attempted in these runs. Waiting for registry access would not change either fixture's local failure.

This is a P3 diagnostic defect under triage/v1: no additional update blocker, false success, or destructive behavior was established. Actual frequency and user recovery delays are unknown. npm-owned installations, native Windows/Linux execution, and real Bun failures were not tested.

REA version

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

6.8.0

Baseline: 65f1c447344a423fa2785847dbcea1e9a9e2454a.

Runtime and platform

Node.js v24.22.1; macOS 27.0.1; arm64. Bun and npm executables were locally authored fixtures. No real package-manager version is claimed.

Target and artifact context

A fixture Bun global project with a manifest and a node_modules/rea-agents symlink to the built checkout. No analysis target or native provider was involved.

Interface

CLI

Earliest failure stage

Setup or provider admission

Relevant output or evidence

The JSON in Observed behavior came from the public CLI with the failing launcher. The missing-launcher run returned:

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

The shell replay printed the following status and invocation-log lines after the two results:

failing exit=1
bun --version
missing exit=1

The logs establish that no metadata command executed; latestVersion: null alone would not establish that.

Independent controls used the same global-project layout and isolated environment. A fixture returning 1.2.16, and one returning not-a-version, each exited 1 with Upgrade Bun manually advice and only a version-probe invocation. A fixture returning 1.2.17 followed by metadata "6.8.0" yielded:

{"status":"current","currentVersion":"6.8.0","latestVersion":"6.8.0","installMethod":"bun"}

That control exited 0 and recorded exactly the version probe and bun info rea-agents dist-tags.latest --json, confirming detection of the fixture as Bun-owned. Each control ran once.

Source references at the baseline:

docs/installation.md:530-541: minimum Bun version, manual recovery for old/unparseable output, owning global directory and manifest requirements.
AGENTS.md, Architecture and Cleanup: meaningful failure reasons and tagged expected failures.
src/cli/setupCommands.ts:183-204: supported CLI registration and system update host.
src/application/UpdateRuntime.ts:112-147: canonical package identity and global-manifest ownership guard.
src/application/UpdateRuntime.ts:266-280: unsuccessful version probes become unavailable; old/unparseable successful probes receive Bun-specific recovery.
src/application/Update.ts:124-130: registry-retry remediation for unavailable.
src/application/Update.ts:179-190: public version-check failure returned before installation.

Typed outcome or recovery expected

Preserve failed and the underlying diagnostic, with recovery that names the local Bun executable problem. The existing public version-check reason also appears in the working old/unparseable-version controls and does not itself establish a defect.

Analysis or suspected cause

Source-derived: the unsuccessful bun --version branch uses the same internal release-lookup failure category that renders registry-retry advice. A successful but unacceptable version takes the separate Bun-specific branch. This explains why changing whether the version probe exits successfully changes the recovery subsystem even though both failures happen before release lookup.

Additional context

Duplicate searches included open and closed issues, all PR states, issue comments, and related PR review comments. Related records have different triggers: #1123/#1138 concern npm metadata parsing; #1735 introduces Bun-global updates and handles old Bun; #5061 concerns ownership; #4888 concerns output retention; #3556/#7216 concern post-update Frida readiness. No matching report or fix was found. No regression from a known-good version is claimed.

Triage assessment

Impact level: P3
Assessment status: supported
Impact basis: The observed defect is recovery wording. The updater still fails correctly, preserves the local executable error, and never reaches installation in these cases.
Workaround status: unverified
Workaround basis: The retained subprocess error identifies the local cause, but recovery with a repaired real Bun installation was not exercised. The supported-version fixture establishes only that valid probe output reaches metadata lookup.

Originally created by @coygeek on GitHub (Oct 27, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7597 ### 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 For an installation recognized as Bun-managed, `node scripts/rea.mjs update --json` advises retrying when registry access becomes available if the local `bun --version` command fails. A launcher that prints `fixture: bun runtime cannot start` and exits 7 produces: ```json {"status":"failed","currentVersion":"6.8.0","latestVersion":null,"reason":"version-check","remediation":"REA could not resolve the latest release: fixture: bun runtime cannot start. Retry rea update when registry access is available."} ``` The updater exits 1. Removing the Bun executable produces the same registry advice, with `spawn bun ENOENT` as the embedded error. In both cases the failure occurs before a release-metadata command. The subprocess error is retained, but the recommended recovery concerns a different cause. ### Reproduction Each failure variant reproduced twice on the baseline: once with an independent fixture runner and once with the shell fixture below. The fixture commands cannot contact a registry or install a package. 1. Start in the built baseline checkout, with Node.js 24.22.1 first on PATH. Create a disposable fixture directory and arrange automatic cleanup: ```sh verify_root=$(mktemp -d) trap 'rm -rf "$verify_root"' EXIT mkdir -p "$verify_root/bin" "$verify_root/home" "$verify_root/global/node_modules" ln -s "$PWD" "$verify_root/global/node_modules/rea-agents" ln -s "$(command -v node)" "$verify_root/bin/node" printf '{"name":"fixture-global"}\n' > "$verify_root/global/package.json" ``` 2. Supply recording, offline package-manager fixtures: ```sh cat > "$verify_root/bin/bun" <<'BUN' #!/bin/sh printf 'bun %s\n' "$*" >> "$VERIFY_CALLS" echo 'fixture: bun runtime cannot start' >&2 exit 7 BUN cat > "$verify_root/bin/npm" <<'NPM' #!/bin/sh printf 'npm %s\n' "$*" >> "$VERIFY_CALLS" echo 'unexpected npm call' >&2 exit 93 NPM chmod +x "$verify_root/bin/bun" "$verify_root/bin/npm" ``` 3. Exercise a failing launcher and then a missing launcher with isolated HOME/XDG settings and restricted PATH. Use a shell without `set -e` so the expected exit 1 does not interrupt the second variant: ```sh for verify_mode in failing missing; do [ "$verify_mode" != missing ] || rm "$verify_root/bin/bun" : > "$verify_root/calls.log" env -i PATH="$verify_root/bin:/usr/bin:/bin" \ HOME="$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" \ BUN_INSTALL_GLOBAL_DIR="$verify_root/global" \ VERIFY_CALLS="$verify_root/calls.log" \ node scripts/rea.mjs update --json verify_exit=$? printf '%s exit=%s\n' "$verify_mode" "$verify_exit" cat "$verify_root/calls.log" done ``` Both commands exit 1 and recommend waiting for registry access. The first log contains only `bun --version`; the second is empty. Neither run invokes npm, a metadata lookup, or an installer. The fixture allocation during verification used a designated scratch parent; its contents were otherwise as shown and were deleted afterward. ### Expected behavior A local Bun executable failure should produce Bun-specific recovery guidance, such as making Bun available on PATH or repairing its launcher, while preserving the actual subprocess error. The installation guide documents Bun 1.2.17 as the updater minimum and promises manual Bun recovery when its version is old or unparseable. It does not explicitly prescribe missing-executable wording. The repository's failure-model invariant also requires meaningful failure reasons. Together with the fact that metadata lookup has not started, these support identifying the local Bun failure rather than recommending recovery of registry access. Exact source references are in Evidence below. The failed status, nonzero exit, and public `reason: "version-check"` can remain unchanged. ### Impact and scope The verified impact is misleading recovery wording for a Bun-owned installation whose version probe cannot start or exits unsuccessfully. The updater correctly fails and retains the Bun error. No package installation was attempted in these runs. Waiting for registry access would not change either fixture's local failure. This is a P3 diagnostic defect under triage/v1: no additional update blocker, false success, or destructive behavior was established. Actual frequency and user recovery delays are unknown. npm-owned installations, native Windows/Linux execution, and real Bun failures were not tested. ### REA version Exact `node scripts/rea.mjs --version` stdout: ```text 6.8.0 ``` Baseline: `65f1c447344a423fa2785847dbcea1e9a9e2454a`. ### Runtime and platform Node.js `v24.22.1`; macOS `27.0.1`; `arm64`. Bun and npm executables were locally authored fixtures. No real package-manager version is claimed. ### Target and artifact context A fixture Bun global project with a manifest and a `node_modules/rea-agents` symlink to the built checkout. No analysis target or native provider was involved. ### Interface CLI ### Earliest failure stage Setup or provider admission ### Relevant output or evidence The JSON in Observed behavior came from the public CLI with the failing launcher. The missing-launcher run returned: ```json {"status":"failed","currentVersion":"6.8.0","latestVersion":null,"reason":"version-check","remediation":"REA could not resolve the latest release: spawn bun ENOENT. Retry rea update when registry access is available."} ``` The shell replay printed the following status and invocation-log lines after the two results: ```text failing exit=1 bun --version missing exit=1 ``` The logs establish that no metadata command executed; `latestVersion: null` alone would not establish that. Independent controls used the same global-project layout and isolated environment. A fixture returning `1.2.16`, and one returning `not-a-version`, each exited 1 with `Upgrade Bun manually` advice and only a version-probe invocation. A fixture returning `1.2.17` followed by metadata `"6.8.0"` yielded: ```json {"status":"current","currentVersion":"6.8.0","latestVersion":"6.8.0","installMethod":"bun"} ``` That control exited 0 and recorded exactly the version probe and `bun info rea-agents dist-tags.latest --json`, confirming detection of the fixture as Bun-owned. Each control ran once. Source references at the baseline: - `docs/installation.md:530-541`: minimum Bun version, manual recovery for old/unparseable output, owning global directory and manifest requirements. - `AGENTS.md`, Architecture and Cleanup: meaningful failure reasons and tagged expected failures. - `src/cli/setupCommands.ts:183-204`: supported CLI registration and system update host. - `src/application/UpdateRuntime.ts:112-147`: canonical package identity and global-manifest ownership guard. - `src/application/UpdateRuntime.ts:266-280`: unsuccessful version probes become `unavailable`; old/unparseable successful probes receive Bun-specific recovery. - `src/application/Update.ts:124-130`: registry-retry remediation for `unavailable`. - `src/application/Update.ts:179-190`: public version-check failure returned before installation. ### Typed outcome or recovery expected Preserve `failed` and the underlying diagnostic, with recovery that names the local Bun executable problem. The existing public `version-check` reason also appears in the working old/unparseable-version controls and does not itself establish a defect. ### Analysis or suspected cause Source-derived: the unsuccessful `bun --version` branch uses the same internal release-lookup failure category that renders registry-retry advice. A successful but unacceptable version takes the separate Bun-specific branch. This explains why changing whether the version probe exits successfully changes the recovery subsystem even though both failures happen before release lookup. ### Additional context Duplicate searches included open and closed issues, all PR states, issue comments, and related PR review comments. Related records have different triggers: #1123/#1138 concern npm metadata parsing; #1735 introduces Bun-global updates and handles old Bun; #5061 concerns ownership; #4888 concerns output retention; #3556/#7216 concern post-update Frida readiness. No matching report or fix was found. No regression from a known-good version is claimed. ## Triage assessment - Impact level: P3 - Assessment status: supported - Impact basis: The observed defect is recovery wording. The updater still fails correctly, preserves the local executable error, and never reaches installation in these cases. - Workaround status: unverified - Workaround basis: The retained subprocess error identifies the local cause, but recovery with a repaired real Bun installation was not exercised. The supported-version fixture establishes only that valid probe output reaches metadata lookup.

bsakaguchi closed this issue

2026-10-31 00:50:31 +00:00

bsakaguchi referenced this issue

2026-10-31 01:12:51 +00:00

[PR #4416] [MERGED] fix(dotnet): reject unfinished CIL prefix chains #6227

bsakaguchi referenced this issue

2026-10-31 01:13:19 +00:00

[PR #4528] [CLOSED] fix(dotnet): reject unfinished CIL prefix chain at end of method body #6288