morluto/rea

Fork 0

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

[GH-ISSUE #1123] fix(update): version lookup fails with npm 12 #394

New issue

Closed

opened 2026-10-15 18:24:43 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:24:43 +00:00

Owner

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

Summary

rea update --json rejects successful npm registry responses when npm 12 is first on PATH. The command exits 1 before determining whether REA is current or installing a newer release. Its remediation incorrectly advises retrying when registry access is available, even though the registry lookup succeeds.

Runtime or environment

Published builds tested: rea-agents 5.0.0 and 6.0.0. The latter was the registry's latest release during verification and matches tag rea-agents-6.0.0 at commit 6fee42689ae6e95a0182e0d4d0f55644e73e72be.
Current default branch inspected: main at 84a17d55199b1b46493aea6bf4e41029a3b200fc. The updater workflow and runtime source files are byte-identical to the release tag. This checkout was inspected as source; I did not build or execute its complete CLI.
Executed platform: macOS 27.0 arm64, Node.js 22.23.2, npm 12.0.2. Control: npm 11.19.1. The Node.js version satisfies the package's declared runtime range, ^22.19.0 || ^24.11.0 || >=26.0.0.
Each install used a disposable HOME, npm cache, and global prefix. No provider or target artifact is involved.

Steps to reproduce

Start with a supported Node.js runtime and npm available. The commands below install the failing npm version and REA in disposable directories, then run the update command. This is the shell equivalent of the executed isolated subprocess sequence.

scratch=$(mktemp -d)
node_dir=$(dirname "$(node -p process.execPath)")
unset CLAUDE_CONFIG_DIR CODEX_HOME COPILOT_HOME OPENCODE_CONFIG XDG_CONFIG_HOME
export HOME="$scratch/home"
export npm_config_cache="$scratch/cache"
export npm_config_prefix="$scratch/prefix"
export PATH="$node_dir:$PATH"
mkdir -p "$HOME"
npm install --prefix "$scratch/npm12" --ignore-scripts --no-audit --no-fund npm@12.0.2
export PATH="$scratch/npm12/node_modules/.bin:$PATH"
npm --version
npm install --global --prefix "$scratch/rea" --ignore-scripts --no-audit --no-fund rea-agents@6.0.0
npm view --global --prefix "$scratch/rea" rea-agents dist-tags.latest --json
"$scratch/rea/bin/rea" update --json
printf 'exit=%s\n' "$?"

The registry command exits 0 and returns an array containing the latest version. The update command exits 1. The same failure was observed after installing the older published build globally and from npx -y rea-agents@6.0.0 update --json under the same isolated environment.

For a control, install npm 11 in another disposable prefix and put its node_modules/.bin first on PATH. With that PATH change, the older global install upgrades and its executable reports the latest release. A global install already at the latest release reports status: "current", with exit 0.

Expected behavior

The updater should resolve the latest release from a successful response under npm's documented JSON output contract. For a global installation already at the latest version, it should return status: "current" and exit 0. For an older global installation, it should install and verify the newer release. Any recovery advice should identify the actual failure rather than imply unavailable registry access.

Actual behavior

The current published global install returned this complete JSON document and exited 1:

{
  "status": "failed",
  "currentVersion": "6.0.0",
  "latestVersion": null,
  "reason": "version-check",
  "remediation": "REA could not resolve the latest release: Invalid npm release metadata: [\n  {\n    \"expected\": \"string\",\n    \"code\": \"invalid_type\",\n    \"path\": [],\n    \"message\": \"Invalid input: expected string, received array\"\n  }\n]. Retry rea update when registry access is available."
}

The older global install and the package-runner invocation also exited 1 with the same reason and validation message. There was one executed failing update attempt for each of those three installation cases.

The exact field queried by REA returned the following output under the failing npm version, with exit 0:

[
  "6.0.0"
]

The control npm version returned a JSON string instead, also with exit 0:

"6.0.0"

npm view rea-agents version --json showed the same array-versus-string difference. Under the control PATH, the older install returned status: "updated", verified its new executable version, and exited 0. The current global install returned status: "current" and exited 0.

Evidence

Expected source: Installation guide, update contract documents exact release lookup, installation into the owning npm prefix, and executable-version verification. npm's documented JSON output explicitly says scalar and object results are returned in an array even for a single matching version.
Failure source: The executed isolated update and registry commands produced the output and exit statuses in Actual behavior. Current updater runtime queries dist-tags.latest and accepts only a nonempty JSON string. Current update workflow converts that parse failure into the observed result and registry-access remediation.
Evidence provenance: observed
Local verification: reproduced
Reproduction completeness: complete

The CLI failures and successful controls were executed; the unchanged default-branch parser was verified separately by source inspection and comparison with the release tag. The npm output change is intentional. npm 12 release notes list the breaking change, "npm view --json now always returns an array." This is a REA consumer compatibility failure, rather than evidence of a registry outage or an npm defect.

Restoration check

Repeat the isolated registry and update commands with npm 12 first on PATH. A global installation already at the registry's latest release must return that release as latestVersion, report status: "current", and exit 0. Repeat from the older global install and confirm status: "updated", the installed executable's version, and exit 0. Retain the npm 11 control to confirm its scalar response still resolves correctly. Invalid release metadata and a genuinely failed registry command should still produce failure results with recovery advice appropriate to the observed cause.

Impact and scope

This blocks the built-in update/version-check workflow for the tested npm 12 installation cases. The failure happens before installation, and an npm 11 PATH override restores the update workflow. The measured runtime scope is the platform above; other operating systems were not executed for this report.

Additional context

Area: Setup, packaging, or upgrade.
Interface: CLI.
Earliest failure stage: Request parsing or validation of the successful npm response.
Target and artifact context: Not applicable.
I searched open and closed issues and pull requests for a related report. No covering report or PR was found.
I removed credentials, tokens, private paths, and sensitive target data.

Triage assessment

Impact level: P2
Assessment status: supported
Impact basis: The built-in updater cannot resolve release metadata in the three tested npm 12 installation cases and exits unsuccessfully despite a successful registry response. This is a bounded compatibility defect in update/version checking.
Workaround status: available
Workaround basis: Putting the tested npm 11 tool first on PATH allowed the older global install to update and verify its executable, and allowed the current global install to report its current status. The controls used disposable prefixes and did not change agent configuration.

Originally created by @coygeek on GitHub (Oct 8, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1123 ## Summary `rea update --json` rejects successful npm registry responses when npm 12 is first on PATH. The command exits 1 before determining whether REA is current or installing a newer release. Its remediation incorrectly advises retrying when registry access is available, even though the registry lookup succeeds. ## Runtime or environment - Published builds tested: `rea-agents` 5.0.0 and 6.0.0. The latter was the registry's latest release during verification and matches tag `rea-agents-6.0.0` at commit `6fee42689ae6e95a0182e0d4d0f55644e73e72be`. - Current default branch inspected: `main` at `84a17d55199b1b46493aea6bf4e41029a3b200fc`. The updater workflow and runtime source files are byte-identical to the release tag. This checkout was inspected as source; I did not build or execute its complete CLI. - Executed platform: macOS 27.0 arm64, Node.js 22.23.2, npm 12.0.2. Control: npm 11.19.1. The Node.js version satisfies the package's declared runtime range, `^22.19.0 || ^24.11.0 || >=26.0.0`. - Each install used a disposable HOME, npm cache, and global prefix. No provider or target artifact is involved. ## Steps to reproduce Start with a supported Node.js runtime and npm available. The commands below install the failing npm version and REA in disposable directories, then run the update command. This is the shell equivalent of the executed isolated subprocess sequence. ```sh scratch=$(mktemp -d) node_dir=$(dirname "$(node -p process.execPath)") unset CLAUDE_CONFIG_DIR CODEX_HOME COPILOT_HOME OPENCODE_CONFIG XDG_CONFIG_HOME export HOME="$scratch/home" export npm_config_cache="$scratch/cache" export npm_config_prefix="$scratch/prefix" export PATH="$node_dir:$PATH" mkdir -p "$HOME" npm install --prefix "$scratch/npm12" --ignore-scripts --no-audit --no-fund npm@12.0.2 export PATH="$scratch/npm12/node_modules/.bin:$PATH" npm --version npm install --global --prefix "$scratch/rea" --ignore-scripts --no-audit --no-fund rea-agents@6.0.0 npm view --global --prefix "$scratch/rea" rea-agents dist-tags.latest --json "$scratch/rea/bin/rea" update --json printf 'exit=%s\n' "$?" ``` The registry command exits 0 and returns an array containing the latest version. The update command exits 1. The same failure was observed after installing the older published build globally and from `npx -y rea-agents@6.0.0 update --json` under the same isolated environment. For a control, install npm 11 in another disposable prefix and put its `node_modules/.bin` first on PATH. With that PATH change, the older global install upgrades and its executable reports the latest release. A global install already at the latest release reports `status: "current"`, with exit 0. ## Expected behavior The updater should resolve the latest release from a successful response under npm's documented JSON output contract. For a global installation already at the latest version, it should return `status: "current"` and exit 0. For an older global installation, it should install and verify the newer release. Any recovery advice should identify the actual failure rather than imply unavailable registry access. ## Actual behavior The current published global install returned this complete JSON document and exited 1: ```json { "status": "failed", "currentVersion": "6.0.0", "latestVersion": null, "reason": "version-check", "remediation": "REA could not resolve the latest release: Invalid npm release metadata: [\n {\n \"expected\": \"string\",\n \"code\": \"invalid_type\",\n \"path\": [],\n \"message\": \"Invalid input: expected string, received array\"\n }\n]. Retry rea update when registry access is available." } ``` The older global install and the package-runner invocation also exited 1 with the same reason and validation message. There was one executed failing update attempt for each of those three installation cases. The exact field queried by REA returned the following output under the failing npm version, with exit 0: ```json [ "6.0.0" ] ``` The control npm version returned a JSON string instead, also with exit 0: ```json "6.0.0" ``` `npm view rea-agents version --json` showed the same array-versus-string difference. Under the control PATH, the older install returned `status: "updated"`, verified its new executable version, and exited 0. The current global install returned `status: "current"` and exited 0. ## Evidence - Expected source: [Installation guide, update contract](https://github.com/morluto/rea/blob/84a17d55199b1b46493aea6bf4e41029a3b200fc/docs/installation.md#L211-L219) documents exact release lookup, installation into the owning npm prefix, and executable-version verification. [npm's documented JSON output](https://github.com/npm/cli/blob/b888cc9a9ff34a8b023ff47b784692396635397b/docs/lib/content/commands/npm-view.md#L171-L179) explicitly says scalar and object results are returned in an array even for a single matching version. - Failure source: The executed isolated update and registry commands produced the output and exit statuses in Actual behavior. [Current updater runtime](https://github.com/morluto/rea/blob/84a17d55199b1b46493aea6bf4e41029a3b200fc/src/application/UpdateRuntime.ts#L130-L150) queries `dist-tags.latest` and accepts only a nonempty JSON string. [Current update workflow](https://github.com/morluto/rea/blob/84a17d55199b1b46493aea6bf4e41029a3b200fc/src/application/Update.ts#L102-L124) converts that parse failure into the observed result and registry-access remediation. - Evidence provenance: observed - Local verification: reproduced - Reproduction completeness: complete The CLI failures and successful controls were executed; the unchanged default-branch parser was verified separately by source inspection and comparison with the release tag. The npm output change is intentional. [npm 12 release notes](https://github.com/npm/cli/releases/tag/v12.0.0) list the breaking change, "npm view --json now always returns an array." This is a REA consumer compatibility failure, rather than evidence of a registry outage or an npm defect. ## Restoration check Repeat the isolated registry and update commands with npm 12 first on PATH. A global installation already at the registry's latest release must return that release as `latestVersion`, report `status: "current"`, and exit 0. Repeat from the older global install and confirm `status: "updated"`, the installed executable's version, and exit 0. Retain the npm 11 control to confirm its scalar response still resolves correctly. Invalid release metadata and a genuinely failed registry command should still produce failure results with recovery advice appropriate to the observed cause. ## Impact and scope This blocks the built-in update/version-check workflow for the tested npm 12 installation cases. The failure happens before installation, and an npm 11 PATH override restores the update workflow. The measured runtime scope is the platform above; other operating systems were not executed for this report. ## Additional context - Area: Setup, packaging, or upgrade. - Interface: CLI. - Earliest failure stage: Request parsing or validation of the successful npm response. - Target and artifact context: Not applicable. - [x] I searched open and closed issues and pull requests for a related report. No covering report or PR was found. - [x] I removed credentials, tokens, private paths, and sensitive target data. ## Triage assessment - Impact level: P2 - Assessment status: supported - Impact basis: The built-in updater cannot resolve release metadata in the three tested npm 12 installation cases and exits unsuccessfully despite a successful registry response. This is a bounded compatibility defect in update/version checking. - Workaround status: available - Workaround basis: Putting the tested npm 11 tool first on PATH allowed the older global install to update and verify its executable, and allowed the current global install to report its current status. The controls used disposable prefixes and did not change agent configuration.

bsakaguchi

2026-10-15 18:24:43 +00:00

closed this issue
added the
area: build

bug
labels

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#394

No description provided.

Rows
Columns