[GH-ISSUE #3306] [Bug] Doctor reports Hopper ready with an invalid startup timeout #1179

New issue

Closed

opened 2026-10-15 18:31:46 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:31:46 +00:00

Owner

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

Before submitting

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

Area

Provider or capability discovery

Observed behavior

doctor --provider hopper reports healthy: true and exits 0 when the calling environment sets REA_HOPPER_STARTUP_TIMEOUT_MS=0. In the same environment, providers rejects the setting with configuration_invalid and exits 1. The scoped readiness check therefore misses a configuration error that prevents the CLI from constructing its analysis runtime.

The observed doctor report has scope.mode: "explicit" and scope.providers: ["hopper"]. Every required check passes: node, host, and hopper. It includes no diagnostic for the invalid timeout. Repeating both commands with REA_HOPPER_STARTUP_TIMEOUT_MS=120000 makes both exit 0, and the scoped doctor report remains healthy.

Reproduction

On macOS with Hopper installed and recognized at its default launcher location, prepare a clean source checkout and its compiled runtime:

git clone https://github.com/morluto/rea.git rea-hopper-timeout-repro
cd rea-hopper-timeout-repro
git checkout 8dde6370d0809ad04cda3342d4e6f290f48aa063
npm ci
npm run build:cached

From the repository root, create an isolated home and run both commands with the invalid timeout. No input file is required. These checks read the launcher and do not start an analysis session:

work_dir=$(mktemp -d)
mkdir -p "$work_dir/home"
env -i PATH="$PATH" HOME="$work_dir/home" REA_HOPPER_STARTUP_TIMEOUT_MS=0 \
  node scripts/rea.mjs providers --json
printf 'providers exit: %s\n' "$?"
env -i PATH="$PATH" HOME="$work_dir/home" REA_HOPPER_STARTUP_TIMEOUT_MS=0 \
  node scripts/rea.mjs doctor --provider hopper --json
printf 'doctor exit: %s\n' "$?"

Observe that providers exits 1 with the named configuration error, while doctor exits 0 with successful Hopper readiness.
Keep the same launcher and isolated home, and repeat both commands with the valid-timeout control:

env -i PATH="$PATH" HOME="$work_dir/home" REA_HOPPER_STARTUP_TIMEOUT_MS=120000 \
  node scripts/rea.mjs providers --json
printf 'providers exit: %s\n' "$?"
env -i PATH="$PATH" HOME="$work_dir/home" REA_HOPPER_STARTUP_TIMEOUT_MS=120000 \
  node scripts/rea.mjs doctor --provider hopper --json
printf 'doctor exit: %s\n' "$?"

Both valid-timeout commands were observed to exit 0, with doctor still healthy. The runtime commands were reproduced against the prepared source build; the clean-checkout installation and build commands above are prerequisites for repeating the reproduction.

Expected behavior

The Hopper readiness check should report the invalid startup timeout and an unsuccessful scoped health result. docs/installation.md:307, under "Check readiness for your task", identifies doctor --provider hopper as the readiness check for that engine. docs/installation.md:582, under "Launcher paths and troubleshooting", defines the admitted setting range as positive decimal integers from 1 to 2,147,483,647 milliseconds and states that invalid values fail configuration validation. Zero prevents runtime configuration from being parsed, so it cannot satisfy readiness for that provider.

Impact and scope

Impact is P2, supported. The documented engine readiness command gives a successful result for a configuration that demonstrably blocks runtime construction. This misdirects troubleshooting for affected Hopper configurations; the observed failure is bounded to invalid environment settings.

A verified workaround is available: setting the timeout to 120000 makes both providers and the scoped doctor check exit 0. The runtime configuration error already identifies the setting and its positive-integer constraint.

REA version

6.4.0 (main at 8dde6370d0)

Runtime and platform

Node.js v26.10.0; macOS 27.0.1; arm64. The reproduction used an isolated home and an existing Hopper installation recognized at the default launcher location. The Hopper version was not recorded.

Target and artifact context

The environment passed to the CLI is the relevant input. No analysis target, input artifact, or saved client registration is involved. The checks require no Hopper process or client configuration change.

Interface

CLI

Earliest failure stage

Setup or provider admission

Relevant output or evidence

The observed providers error object and selected doctor fields are:

{
  "error": {
    "code": "configuration_invalid",
    "message": "REA configuration is invalid: REA_HOPPER_STARTUP_TIMEOUT_MS: must be a positive decimal integer.",
    "details": {
      "settings": [
        {
          "setting": "REA_HOPPER_STARTUP_TIMEOUT_MS",
          "constraint": "must be a positive decimal integer"
        }
      ]
    }
  }
}
providers exit: 1
doctor exit: 0
doctor: healthy=true; scope.mode="explicit"; scope.providers=["hopper"]
doctor: required checks node, host, hopper all pass; no invalid-timeout diagnostic
120000 control: providers exit 0; doctor exit 0; doctor healthy=true

Typed outcome or recovery expected

Repeat the zero-timeout reproduction. Doctor must identify REA_HOPPER_STARTUP_TIMEOUT_MS as invalid, report unsuccessful Hopper readiness, and exit nonzero. With the same launcher and timeout 120000, providers and the scoped doctor check must continue to exit 0. No Hopper process or client configuration change is required for these checks.

Analysis or suspected cause

Source-derived reasoning: src/cli/setupCommands.ts:124 reaches the doctor runtime directly, and src/application/DoctorDiagnostics.ts:27 collects its diagnostics without validating this setting. These paths explain the observed disagreement between runtime configuration validation and the scoped readiness result. The executed CLI commands and output establish the failure; the source locators explain the missing validation.

Additional context

Related #3054 concerns different Hopper launcher resolution between doctor and the CLI runtime; this report uses the recognized default launcher and concerns timeout validation.
Related #3205 concerns an invalid persisted MCP output-schema profile in client-registration readiness; this report concerns the calling environment of provider-scoped doctor.
Related closed #1183 concerns relative Ghidra path admission in doctor and setup; this report concerns the positive-integer Hopper timeout constraint.
Related closed #1184 concerns configuration errors that omit the rejected Ghidra setting; the runtime error here already names the rejected timeout and its constraint.
Related closed #2665 concerns invalid retained client-registration loader/compiler overrides; validating registrations does not validate the calling environment of provider-scoped doctor.
Related #1808 and closed #3268 concern Hopper startup deadlines and configurability; this report concerns doctor accepting an invalid value for the existing timeout setting.
Related closed #2459 concerns Linux Hopper process ownership and recovery while doctor stays healthy; no Hopper process runs in this reproduction.
Related #3179 concerns malformed Ghidra metadata passing version validation; this report requires validation of a Hopper environment setting.
Related #3008 concerns incomplete provider inspection and discovery coverage; this report concerns a named setting in the existing Hopper readiness check.

Originally created by @coygeek on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3306 ### 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 Provider or capability discovery ### Observed behavior `doctor --provider hopper` reports `healthy: true` and exits 0 when the calling environment sets `REA_HOPPER_STARTUP_TIMEOUT_MS=0`. In the same environment, `providers` rejects the setting with `configuration_invalid` and exits 1. The scoped readiness check therefore misses a configuration error that prevents the CLI from constructing its analysis runtime. The observed doctor report has `scope.mode: "explicit"` and `scope.providers: ["hopper"]`. Every required check passes: `node`, `host`, and `hopper`. It includes no diagnostic for the invalid timeout. Repeating both commands with `REA_HOPPER_STARTUP_TIMEOUT_MS=120000` makes both exit 0, and the scoped doctor report remains healthy. ### Reproduction 1. On macOS with Hopper installed and recognized at its default launcher location, prepare a clean source checkout and its compiled runtime: ```sh git clone https://github.com/morluto/rea.git rea-hopper-timeout-repro cd rea-hopper-timeout-repro git checkout 8dde6370d0809ad04cda3342d4e6f290f48aa063 npm ci npm run build:cached ``` 2. From the repository root, create an isolated home and run both commands with the invalid timeout. No input file is required. These checks read the launcher and do not start an analysis session: ```bash work_dir=$(mktemp -d) mkdir -p "$work_dir/home" env -i PATH="$PATH" HOME="$work_dir/home" REA_HOPPER_STARTUP_TIMEOUT_MS=0 \ node scripts/rea.mjs providers --json printf 'providers exit: %s\n' "$?" env -i PATH="$PATH" HOME="$work_dir/home" REA_HOPPER_STARTUP_TIMEOUT_MS=0 \ node scripts/rea.mjs doctor --provider hopper --json printf 'doctor exit: %s\n' "$?" ``` 3. Observe that `providers` exits 1 with the named configuration error, while doctor exits 0 with successful Hopper readiness. 4. Keep the same launcher and isolated home, and repeat both commands with the valid-timeout control: ```bash env -i PATH="$PATH" HOME="$work_dir/home" REA_HOPPER_STARTUP_TIMEOUT_MS=120000 \ node scripts/rea.mjs providers --json printf 'providers exit: %s\n' "$?" env -i PATH="$PATH" HOME="$work_dir/home" REA_HOPPER_STARTUP_TIMEOUT_MS=120000 \ node scripts/rea.mjs doctor --provider hopper --json printf 'doctor exit: %s\n' "$?" ``` Both valid-timeout commands were observed to exit 0, with doctor still healthy. The runtime commands were reproduced against the prepared source build; the clean-checkout installation and build commands above are prerequisites for repeating the reproduction. ### Expected behavior The Hopper readiness check should report the invalid startup timeout and an unsuccessful scoped health result. `docs/installation.md:307`, under "Check readiness for your task", identifies `doctor --provider hopper` as the readiness check for that engine. `docs/installation.md:582`, under "Launcher paths and troubleshooting", defines the admitted setting range as positive decimal integers from 1 to 2,147,483,647 milliseconds and states that invalid values fail configuration validation. Zero prevents runtime configuration from being parsed, so it cannot satisfy readiness for that provider. ### Impact and scope Impact is P2, supported. The documented engine readiness command gives a successful result for a configuration that demonstrably blocks runtime construction. This misdirects troubleshooting for affected Hopper configurations; the observed failure is bounded to invalid environment settings. A verified workaround is available: setting the timeout to `120000` makes both `providers` and the scoped doctor check exit 0. The runtime configuration error already identifies the setting and its positive-integer constraint. ### REA version 6.4.0 (main at 8dde6370d0809ad04cda3342d4e6f290f48aa063) ### Runtime and platform Node.js v26.10.0; macOS 27.0.1; arm64. The reproduction used an isolated home and an existing Hopper installation recognized at the default launcher location. The Hopper version was not recorded. ### Target and artifact context The environment passed to the CLI is the relevant input. No analysis target, input artifact, or saved client registration is involved. The checks require no Hopper process or client configuration change. ### Interface CLI ### Earliest failure stage Setup or provider admission ### Relevant output or evidence The observed `providers` error object and selected doctor fields are: ```text { "error": { "code": "configuration_invalid", "message": "REA configuration is invalid: REA_HOPPER_STARTUP_TIMEOUT_MS: must be a positive decimal integer.", "details": { "settings": [ { "setting": "REA_HOPPER_STARTUP_TIMEOUT_MS", "constraint": "must be a positive decimal integer" } ] } } } providers exit: 1 doctor exit: 0 doctor: healthy=true; scope.mode="explicit"; scope.providers=["hopper"] doctor: required checks node, host, hopper all pass; no invalid-timeout diagnostic 120000 control: providers exit 0; doctor exit 0; doctor healthy=true ``` ### Typed outcome or recovery expected Repeat the zero-timeout reproduction. Doctor must identify `REA_HOPPER_STARTUP_TIMEOUT_MS` as invalid, report unsuccessful Hopper readiness, and exit nonzero. With the same launcher and timeout `120000`, `providers` and the scoped doctor check must continue to exit 0. No Hopper process or client configuration change is required for these checks. ### Analysis or suspected cause Source-derived reasoning: `src/cli/setupCommands.ts:124` reaches the doctor runtime directly, and `src/application/DoctorDiagnostics.ts:27` collects its diagnostics without validating this setting. These paths explain the observed disagreement between runtime configuration validation and the scoped readiness result. The executed CLI commands and output establish the failure; the source locators explain the missing validation. ### Additional context - Related [#3054](https://github.com/morluto/rea/issues/3054) concerns different Hopper launcher resolution between doctor and the CLI runtime; this report uses the recognized default launcher and concerns timeout validation. - Related [#3205](https://github.com/morluto/rea/issues/3205) concerns an invalid persisted MCP output-schema profile in client-registration readiness; this report concerns the calling environment of provider-scoped doctor. - Related closed [#1183](https://github.com/morluto/rea/issues/1183) concerns relative Ghidra path admission in doctor and setup; this report concerns the positive-integer Hopper timeout constraint. - Related closed [#1184](https://github.com/morluto/rea/issues/1184) concerns configuration errors that omit the rejected Ghidra setting; the runtime error here already names the rejected timeout and its constraint. - Related closed [#2665](https://github.com/morluto/rea/issues/2665) concerns invalid retained client-registration loader/compiler overrides; validating registrations does not validate the calling environment of provider-scoped doctor. - Related [#1808](https://github.com/morluto/rea/issues/1808) and closed [#3268](https://github.com/morluto/rea/issues/3268) concern Hopper startup deadlines and configurability; this report concerns doctor accepting an invalid value for the existing timeout setting. - Related closed [#2459](https://github.com/morluto/rea/issues/2459) concerns Linux Hopper process ownership and recovery while doctor stays healthy; no Hopper process runs in this reproduction. - Related [#3179](https://github.com/morluto/rea/issues/3179) concerns malformed Ghidra metadata passing version validation; this report requires validation of a Hopper environment setting. - Related [#3008](https://github.com/morluto/rea/issues/3008) concerns incomplete provider inspection and discovery coverage; this report concerns a named setting in the existing Hopper readiness check.

bsakaguchi referenced this issue

2026-10-17 21:09:15 +00:00

[PR #1179] [MERGED] fix(server): report 2025-era client identity and features in binary_session #2703

bsakaguchi closed this issue

2026-10-31 00:30:00 +00:00