morluto/rea

Fork 0

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

[GH-ISSUE #5834] [Bug] Kuna doctor recommends changing the executable for invalid cache, jobs and timeout settings #3529

New issue

Closed

opened 2026-10-31 00:41:33 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-31 00:41:33 +00:00

Owner

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

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

Executed node scripts/rea.mjs doctor --provider kuna --json with an absolute path to a harmless fake Kuna executable and one invalid non-command setting. In all five cases, doctor correctly rejected the setting but recommended setting REA_KUNA_COMMAND to an absolute executable path. The same executable passed doctor when the invalid override was removed.

For example, REA_KUNA_JOBS=99 produced open_options_invalid, a detail saying jobs must be from 1 to 32, and details.setting: "REA_KUNA_JOBS". Its remediation nevertheless instructed the caller to set REA_KUNA_COMMAND. The setting and reason survive; the recovery instruction contradicts them.

Reproduction

From the built source checkout with dependencies installed, run the following with Node 24.18.0 on PATH. This is the executed CLI matrix reduced to a disposable fixture directory; it uses a fake version executable, no analysis target and no live provider. All configuration roots are isolated.

python3 - <<'PY'
import json, os, pathlib, shutil, subprocess, tempfile
node = shutil.which('node')
with tempfile.TemporaryDirectory(prefix='rea-kuna-repro-') as directory:
    root = pathlib.Path(directory)
    for name in ('home', 'config', 'data', 'cache', 'state', 'tmp'):
        (root / name).mkdir()
    kuna = root / 'kuna'
    kuna.write_text('#!' + node + '\nconsole.log("kuna 1.833");\n')
    kuna.chmod(0o700)
    env = {
        'PATH': str(pathlib.Path(node).parent) + ':/usr/bin:/bin',
        'HOME': str(root / 'home'), 'USERPROFILE': str(root / 'home'),
        'TMPDIR': str(root / 'tmp'), 'REA_LOG_LEVEL': 'silent',
        'REA_KUNA_COMMAND': str(kuna),
        'REA_KUNA_CACHE_DIR': str(root / 'cache' / 'kuna'),
        'HOPPER_LAUNCHER_PATH': str(root / 'missing-hopper'),
        'GHIDRA_INSTALL_DIR': str(root / 'missing-ghidra'),
    }
    for kind in ('CONFIG', 'DATA', 'CACHE', 'STATE'):
        env['XDG_' + kind + '_HOME'] = str(root / kind.lower())
    cases = [('REA_KUNA_JOBS', '99'),
             ('REA_KUNA_CACHE_DIR', 'relative/cache'),
             ('REA_KUNA_CACHE_MAX_BYTES', '0'),
             ('REA_KUNA_PROJECT_TIMEOUT_MS', 'abc'),
             ('REA_KUNA_TIMEOUT_MS', 'abc'), ('control', None)]
    for setting, value in cases:
        child_env = env.copy()
        if value is not None:
            child_env[setting] = value
        run = subprocess.run(
            [node, 'scripts/rea.mjs', 'doctor', '--provider', 'kuna', '--json'],
            env=child_env, capture_output=True, text=True, timeout=40)
        report = json.loads(run.stdout)
        provider = next(p for p in report['providerInspections']
                        if p['id'] == 'kuna')
        check = provider['checks'][0]
        print(json.dumps({'setting': setting, 'exit': run.returncode,
                          'healthy': report['healthy'],
                          'code': check['code'], 'detail': check['detail'],
                          'remediation': check['remediation']}))
PY

Each invalid case reproduced once in the final pinned-Node matrix. The control exited 0 and reported healthy and available with the same command. An earlier matrix under Node 26.12.0 also reproduced all five incorrect remediations, but its restricted-PATH control failed during cleanup; the results below use the final pinned-Node run.

Expected behavior

The recovery instruction should identify the rejected setting and tell the caller to correct it before rerunning doctor. The installation guide explicitly says to follow the remediation for the failed check. Kuna's configuration table distinguishes the executable from the cache, jobs and timeout settings.

Impact and scope

P2: callers receive an ineffective recovery action for five bounded configuration errors. Following it does not correct the setting doctor rejected. Doctor still exits 1, reports unhealthy, and retains the accurate detail and setting, so reading those fields provides a practical workaround. Correcting the invalid override restored readiness in the control without changing the command.

This verifies diagnostic recovery on macOS using a fake executable. Linux follows the same source mapping but was not executed. No setup mutation, real-provider analysis, target execution, evidence loss or security boundary crossing was tested or observed. Production frequency is unknown.

REA version

rea-agents 6.7.0; source baseline a5f982de8d; prebuilt CLI runtime in that checkout.

Runtime and platform

Node.js v24.18.0; macOS 27.0.1 arm64; fake Kuna prints kuna 1.833; no real Kuna installation used.

Target and artifact context

No binary target or analysis database; isolated environment roots and one harmless version-printing executable.

Interface

CLI

Earliest failure stage

Setup or provider admission

Relevant output or evidence

Trimmed output from the final CLI matrix, retaining the jobs check's actual fields:

{
  "setting": "REA_KUNA_JOBS",
  "value": "99",
  "exit": 1,
  "healthy": false,
  "available": false,
  "check": {
    "name": "installation",
    "ok": false,
    "code": "open_options_invalid",
    "detail": "REA_KUNA_JOBS must be an integer from 1 to 32; received 99.",
    "remediation": "Set REA_KUNA_COMMAND to the absolute path of a caller-supplied kuna executable (verified with 1.833). REA does not download, install or update Kuna.",
    "details": {"configured": true, "setting": "REA_KUNA_JOBS"}
  }
}

The other four invalid cases also exited 1, reported unhealthy/unavailable, preserved their respective setting in details.setting, and emitted the same remediation. The control returned exit 0, healthy: true, available: true, installation ok: true, code: null, and remediation: null.

These code and diagnostic fields come from providerInspections[id=kuna].checks[name=installation]. The flattened scope_checks entry is named kuna-installation; it preserves the remediation and details but has no code field.

Typed outcome or recovery expected

Keep the accurate open_options_invalid check, rejected setting and reason; provide recovery guidance for that specific setting. No change to successful executable validation is needed to explain this failure.

Analysis or suspected cause

Source-derived: configuration parsing assigns the same failure code to these settings. Installation inspection forwards the setting before executable inspection. Doctor's failure mapping selects the command remediation for that code, ignoring the setting when choosing the action. The shared doctor projection then publishes it unchanged.

Additional context

Read-only issue and PR searches found no matching report. Existing #5554 concerns a dangling cache root incorrectly passing readiness; #5105 concerns setup advertising Kuna after a cache check fails. Both are distinct from a correctly rejected environment setting carrying recovery instructions for the wrong variable. No last-known-good version or regression range was established.

Originally created by @coygeek on GitHub (Oct 21, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5834 ### 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 Executed `node scripts/rea.mjs doctor --provider kuna --json` with an absolute path to a harmless fake Kuna executable and one invalid non-command setting. In all five cases, doctor correctly rejected the setting but recommended setting `REA_KUNA_COMMAND` to an absolute executable path. The same executable passed doctor when the invalid override was removed. For example, `REA_KUNA_JOBS=99` produced `open_options_invalid`, a detail saying jobs must be from 1 to 32, and `details.setting: "REA_KUNA_JOBS"`. Its remediation nevertheless instructed the caller to set `REA_KUNA_COMMAND`. The setting and reason survive; the recovery instruction contradicts them. ### Reproduction From the built source checkout with dependencies installed, run the following with Node 24.18.0 on PATH. This is the executed CLI matrix reduced to a disposable fixture directory; it uses a fake version executable, no analysis target and no live provider. All configuration roots are isolated. ```sh python3 - <<'PY' import json, os, pathlib, shutil, subprocess, tempfile node = shutil.which('node') with tempfile.TemporaryDirectory(prefix='rea-kuna-repro-') as directory: root = pathlib.Path(directory) for name in ('home', 'config', 'data', 'cache', 'state', 'tmp'): (root / name).mkdir() kuna = root / 'kuna' kuna.write_text('#!' + node + '\nconsole.log("kuna 1.833");\n') kuna.chmod(0o700) env = { 'PATH': str(pathlib.Path(node).parent) + ':/usr/bin:/bin', 'HOME': str(root / 'home'), 'USERPROFILE': str(root / 'home'), 'TMPDIR': str(root / 'tmp'), 'REA_LOG_LEVEL': 'silent', 'REA_KUNA_COMMAND': str(kuna), 'REA_KUNA_CACHE_DIR': str(root / 'cache' / 'kuna'), 'HOPPER_LAUNCHER_PATH': str(root / 'missing-hopper'), 'GHIDRA_INSTALL_DIR': str(root / 'missing-ghidra'), } for kind in ('CONFIG', 'DATA', 'CACHE', 'STATE'): env['XDG_' + kind + '_HOME'] = str(root / kind.lower()) cases = [('REA_KUNA_JOBS', '99'), ('REA_KUNA_CACHE_DIR', 'relative/cache'), ('REA_KUNA_CACHE_MAX_BYTES', '0'), ('REA_KUNA_PROJECT_TIMEOUT_MS', 'abc'), ('REA_KUNA_TIMEOUT_MS', 'abc'), ('control', None)] for setting, value in cases: child_env = env.copy() if value is not None: child_env[setting] = value run = subprocess.run( [node, 'scripts/rea.mjs', 'doctor', '--provider', 'kuna', '--json'], env=child_env, capture_output=True, text=True, timeout=40) report = json.loads(run.stdout) provider = next(p for p in report['providerInspections'] if p['id'] == 'kuna') check = provider['checks'][0] print(json.dumps({'setting': setting, 'exit': run.returncode, 'healthy': report['healthy'], 'code': check['code'], 'detail': check['detail'], 'remediation': check['remediation']})) PY ``` Each invalid case reproduced once in the final pinned-Node matrix. The control exited 0 and reported healthy and available with the same command. An earlier matrix under Node 26.12.0 also reproduced all five incorrect remediations, but its restricted-PATH control failed during cleanup; the results below use the final pinned-Node run. ### Expected behavior The recovery instruction should identify the rejected setting and tell the caller to correct it before rerunning doctor. The installation guide explicitly says to [follow the remediation for the failed check](https://github.com/morluto/rea/blob/a5f982de8dbe4b092cc20ab89d492b7e7028b758/docs/installation.md#L350-L355). Kuna's [configuration table](https://github.com/morluto/rea/blob/a5f982de8dbe4b092cc20ab89d492b7e7028b758/docs/kuna-provider.md#L24-L31) distinguishes the executable from the cache, jobs and timeout settings. ### Impact and scope P2: callers receive an ineffective recovery action for five bounded configuration errors. Following it does not correct the setting doctor rejected. Doctor still exits 1, reports unhealthy, and retains the accurate detail and setting, so reading those fields provides a practical workaround. Correcting the invalid override restored readiness in the control without changing the command. This verifies diagnostic recovery on macOS using a fake executable. Linux follows the same source mapping but was not executed. No setup mutation, real-provider analysis, target execution, evidence loss or security boundary crossing was tested or observed. Production frequency is unknown. ### REA version rea-agents 6.7.0; source baseline a5f982de8dbe4b092cc20ab89d492b7e7028b758; prebuilt CLI runtime in that checkout. ### Runtime and platform Node.js v24.18.0; macOS 27.0.1 arm64; fake Kuna prints kuna 1.833; no real Kuna installation used. ### Target and artifact context No binary target or analysis database; isolated environment roots and one harmless version-printing executable. ### Interface CLI ### Earliest failure stage Setup or provider admission ### Relevant output or evidence Trimmed output from the final CLI matrix, retaining the jobs check's actual fields: ```json { "setting": "REA_KUNA_JOBS", "value": "99", "exit": 1, "healthy": false, "available": false, "check": { "name": "installation", "ok": false, "code": "open_options_invalid", "detail": "REA_KUNA_JOBS must be an integer from 1 to 32; received 99.", "remediation": "Set REA_KUNA_COMMAND to the absolute path of a caller-supplied kuna executable (verified with 1.833). REA does not download, install or update Kuna.", "details": {"configured": true, "setting": "REA_KUNA_JOBS"} } } ``` The other four invalid cases also exited 1, reported unhealthy/unavailable, preserved their respective setting in `details.setting`, and emitted the same remediation. The control returned exit 0, `healthy: true`, `available: true`, installation `ok: true`, `code: null`, and `remediation: null`. These code and diagnostic fields come from `providerInspections[id=kuna].checks[name=installation]`. The flattened `scope_checks` entry is named `kuna-installation`; it preserves the remediation and details but has no `code` field. ### Typed outcome or recovery expected Keep the accurate `open_options_invalid` check, rejected setting and reason; provide recovery guidance for that specific setting. No change to successful executable validation is needed to explain this failure. ### Analysis or suspected cause Source-derived: [configuration parsing](https://github.com/morluto/rea/blob/a5f982de8dbe4b092cc20ab89d492b7e7028b758/src/kuna/KunaConfiguration.ts#L123-L174) assigns the same failure code to these settings. [Installation inspection](https://github.com/morluto/rea/blob/a5f982de8dbe4b092cc20ab89d492b7e7028b758/src/kuna/KunaInstallation.ts#L352-L363) forwards the setting before executable inspection. [Doctor's failure mapping](https://github.com/morluto/rea/blob/a5f982de8dbe4b092cc20ab89d492b7e7028b758/src/kuna/KunaDoctor.ts#L190-L211) selects the command remediation for that code, ignoring the setting when choosing the action. The [shared doctor projection](https://github.com/morluto/rea/blob/a5f982de8dbe4b092cc20ab89d492b7e7028b758/src/application/DoctorDiagnostics.ts#L363-L377) then publishes it unchanged. ### Additional context Read-only issue and PR searches found no matching report. Existing [#5554](https://github.com/morluto/rea/issues/5554) concerns a dangling cache root incorrectly passing readiness; [#5105](https://github.com/morluto/rea/issues/5105) concerns setup advertising Kuna after a cache check fails. Both are distinct from a correctly rejected environment setting carrying recovery instructions for the wrong variable. No last-known-good version or regression range was established.

bsakaguchi closed this issue

2026-10-31 00:41:33 +00:00

bsakaguchi commented

2026-10-31 00:41:33 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 21, 2026):

Confirmed — the diagnostic detail correctly names the rejected setting (e.g. REA_KUNA_JOBS range 1–32) but the remediation blindly maps the open_options_invalid code to the command-replacement guidance, so following it can never fix the actual failure. The mapping should key off details.setting and emit per-setting recovery (fix the value / use an absolute cache path / provide a numeric timeout), falling back to command guidance only when the executable itself is the rejected setting.

@XinwangTao commented on GitHub (Oct 21, 2026): Confirmed — the diagnostic detail correctly names the rejected setting (e.g. REA_KUNA_JOBS range 1–32) but the remediation blindly maps the open_options_invalid code to the command-replacement guidance, so following it can never fix the actual failure. The mapping should key off details.setting and emit per-setting recovery (fix the value / use an absolute cache path / provide a numeric timeout), falling back to command guidance only when the executable itself is the rejected setting.

bsakaguchi commented

2026-10-31 00:41:34 +00:00

Author

Owner

@coygeek commented on GitHub (Oct 24, 2026):

Checked the reported fix on main at d87e73f2db.

Kuna configuration failures now own their remediation. Non-command settings produce Correct guidance; KunaInstallation forwards it and KunaDoctor honors it before code-based defaults. The regression matrix covers relative cache directory, invalid cache budget, both timeouts and jobs, asserting setting-specific remediation and absence of REA_KUNA_COMMAND advice.

Implementation: KunaConfiguration.ts, KunaDoctor.ts.

The relevant regression checks in kunaDoctor.test.ts passed in the focused test run on this revision. This closure is based on the current source and those checks; provider fixtures do not establish a real-engine run. Closing as completed on main.

@coygeek commented on GitHub (Oct 24, 2026): Checked the reported fix on `main` at d87e73f2db50be72d33a4b3c7199af35518b441c. Kuna configuration failures now own their remediation. Non-command settings produce Correct <setting> guidance; KunaInstallation forwards it and KunaDoctor honors it before code-based defaults. The regression matrix covers relative cache directory, invalid cache budget, both timeouts and jobs, asserting setting-specific remediation and absence of REA_KUNA_COMMAND advice. Implementation: [KunaConfiguration.ts](https://github.com/morluto/rea/blob/d87e73f2db50be72d33a4b3c7199af35518b441c/src/kuna/KunaConfiguration.ts#L90), [KunaDoctor.ts](https://github.com/morluto/rea/blob/d87e73f2db50be72d33a4b3c7199af35518b441c/src/kuna/KunaDoctor.ts#L184). The relevant regression checks in [kunaDoctor.test.ts](https://github.com/morluto/rea/blob/d87e73f2db50be72d33a4b3c7199af35518b441c/tests/boundary/providers/kuna/kunaDoctor.test.ts) passed in the focused test run on this revision. This closure is based on the current source and those checks; provider fixtures do not establish a real-engine run. Closing as completed on main.

bsakaguchi referenced this issue

2026-10-31 01:09:35 +00:00

[PR #3529] feat(reconstruction): verify visual screenshot claims #5808

bsakaguchi referenced this issue

2026-11-01 21:11:07 +00:00

[GH-ISSUE #5654] [Tracker] Open PRs that can't merge yet: conflicts and red CI (October 2026) #3425