morluto/rea

Fork 0

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

[GH-ISSUE #5397] [Bug] Process CLI file errors omit required machine-readable error fields #3267

New issue

Closed

opened 2026-10-31 00:38:34 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

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

Owner

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

Before submitting

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

Area

CLI

Observed behavior

capture-process and compare-process-captures emit JSON diagnostics missing the required code, retryable, and remediation fields when an input file is missing or contains malformed JSON. Each tested failure exits 1 with empty stderr; stdout contains only error, category, and message. With --full-output, the same noncanonical object appears under error alongside ok: false.

An independent verifier executed the cases below. All four affected payloads fail analysisCliErrorEnvelopeSchema; they also fail analysisErrorProjectionSchema after removing the permitted string error label. The two control cases pass both corresponding checks.

Reproduction

Use the prebuilt runtime at the revision below. The verifier used an absolute scripts/rea.mjs entrypoint, absolute input paths, a disposable working directory, and isolated HOME, XDG directories, and TMPDIR. Here $REA_ENTRYPOINT and $CASE_DIR stand for those paths; filenames are normalized, with no private paths included.

Create malformed.json containing not-json and invalid.json containing {} in the case directory. Leave the missing-file names absent. Run:

node "$REA_ENTRYPOINT" capture-process "$CASE_DIR/missing.json" --json
node "$REA_ENTRYPOINT" capture-process "$CASE_DIR/malformed.json" --json
node "$REA_ENTRYPOINT" compare-process-captures "$CASE_DIR/missing-a.json" "$CASE_DIR/missing-b.json" --json
node "$REA_ENTRYPOINT" capture-process "$CASE_DIR/missing.json" --json --full-output

Each case was executed once and showed the missing fields. Controls, also executed once:

node "$REA_ENTRYPOINT" capture-process "$CASE_DIR/invalid.json" --json
node "$REA_ENTRYPOINT" inspect-artifact "$CASE_DIR/missing.bin" --json

The controls exit 1 but return canonical labeled errors (invalid_request and target_unavailable, respectively). No provider or captured executable is needed.

Expected behavior

Source-derived expectation: src/contracts/errorSchemas.ts:21-34 defines the shared CLI/MCP projection with a contracted code, category, nonempty message, boolean retryable, and remediation.action. Lines 81-107 permit an ordinary CLI string label around that projection. docs/error-contract.schema.json requires the same core fields.

File-read and JSON-parse failures should retain an appropriate contracted code and the required recovery fields. Full-output error should contain the canonical projection. Generic details is optional; its absence is not the defect.

Impact and scope

Bounded machine-consumer failure: callers cannot validate these diagnostics against the shared contract or read their code, retryability, and remediation. Exit status and a human-readable cause remain available, so callers can stop and display the message safely.

Observed scope is the four exercised file-read/JSON-parse cases, not every process-command failure. The same command's scenario-validation control already returns a canonical error. No successful capture workflow, data loss, or security boundary failure was demonstrated; broader platform coverage was not tested.

REA version

6.7.0; source commit 074768901f3cdc8205b61773fb1faf6f6c7b3ca8, using its prebuilt runtime. Latest published release checked: rea-agents-6.7.0.

Runtime and platform

Node.js v26.12.0; Darwin, arm64. No Hopper/Ghidra provider was involved.

Target and artifact context

Local process-scenario/capture JSON input files: absent files, not-json, and an empty object control. No executable target or external API.

Interface

CLI

Earliest failure stage

Transport or result projection

Relevant output or evidence

Observed affected payload shape (message summarized to omit input paths):

{"error":"Process command failed","category":"invalid_input","message":"<file-read or invalid-JSON diagnostic>"}

The messages identify ENOENT for missing files or invalid UTF-8 JSON for the malformed file. The full-output case has ok: false and the same three-field object under error. Exported-schema validation from dist/contracts/errorSchemas.js rejected all four affected payloads, including after stripping their string label, while accepting both controls as described above.

Source-derived corroboration at the tested revision: src/application/process/ProcessCli.ts:223-246 translates these file failures into ProcessCliFailure; :264-272 projects only the three observed fields. The typed-error branch at :258-261 retains canonical fields. src/cli/processCommands.ts:19-55 registers both commands. Existing tests/boundary/filesystem/processCliFileInput.test.ts:142-186 asserts the three-field file failures; the verifier inspected that test but did not execute it.

Typed outcome or recovery expected

Keep exit 1 and actionable cause text. Ordinary JSON errors should pass the canonical labeled-envelope schema (or the strict projection when unlabeled). The full-output error member should pass the strict projection schema. Keep both controls passing without relaxing the schemas. These are proposed restoration checks, not an observed fix.

Analysis or suspected cause

Source-derived: the local ProcessCliFailure projection bypasses the canonical typed-error projection. This explains why file-read/JSON-parse failures differ from the valid-JSON scenario-validation control.

Additional context

Prepared with AI assistance and independently reproduced. No repair, full test suite, or real-provider test was performed. NOT_ENOUGH_INFO: no last-known-good version was tested.

Before submission, upstream main was fetched at d532b18123916a9e88f98c7880ba4f984e23d715; no commits since the tested baseline changed the cited contract, command registration, process projection, or CLI logging files. Searches covered open and closed issues and PRs. Related reports #155 and PRs #107, #1080, and #1510 concern different error behavior and do not report these missing canonical fields.

Originally created by @coygeek on GitHub (Oct 20, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5397 ### 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 CLI ### Observed behavior `capture-process` and `compare-process-captures` emit JSON diagnostics missing the required `code`, `retryable`, and `remediation` fields when an input file is missing or contains malformed JSON. Each tested failure exits 1 with empty stderr; stdout contains only `error`, `category`, and `message`. With `--full-output`, the same noncanonical object appears under `error` alongside `ok: false`. An independent verifier executed the cases below. All four affected payloads fail `analysisCliErrorEnvelopeSchema`; they also fail `analysisErrorProjectionSchema` after removing the permitted string `error` label. The two control cases pass both corresponding checks. ### Reproduction Use the prebuilt runtime at the revision below. The verifier used an absolute `scripts/rea.mjs` entrypoint, absolute input paths, a disposable working directory, and isolated HOME, XDG directories, and TMPDIR. Here `$REA_ENTRYPOINT` and `$CASE_DIR` stand for those paths; filenames are normalized, with no private paths included. Create `malformed.json` containing `not-json` and `invalid.json` containing `{}` in the case directory. Leave the missing-file names absent. Run: ```sh node "$REA_ENTRYPOINT" capture-process "$CASE_DIR/missing.json" --json node "$REA_ENTRYPOINT" capture-process "$CASE_DIR/malformed.json" --json node "$REA_ENTRYPOINT" compare-process-captures "$CASE_DIR/missing-a.json" "$CASE_DIR/missing-b.json" --json node "$REA_ENTRYPOINT" capture-process "$CASE_DIR/missing.json" --json --full-output ``` Each case was executed once and showed the missing fields. Controls, also executed once: ```sh node "$REA_ENTRYPOINT" capture-process "$CASE_DIR/invalid.json" --json node "$REA_ENTRYPOINT" inspect-artifact "$CASE_DIR/missing.bin" --json ``` The controls exit 1 but return canonical labeled errors (`invalid_request` and `target_unavailable`, respectively). No provider or captured executable is needed. ### Expected behavior Source-derived expectation: `src/contracts/errorSchemas.ts:21-34` defines the shared CLI/MCP projection with a contracted `code`, `category`, nonempty `message`, boolean `retryable`, and `remediation.action`. Lines 81-107 permit an ordinary CLI string label around that projection. `docs/error-contract.schema.json` requires the same core fields. File-read and JSON-parse failures should retain an appropriate contracted code and the required recovery fields. Full-output `error` should contain the canonical projection. Generic `details` is optional; its absence is not the defect. ### Impact and scope Bounded machine-consumer failure: callers cannot validate these diagnostics against the shared contract or read their code, retryability, and remediation. Exit status and a human-readable cause remain available, so callers can stop and display the message safely. Observed scope is the four exercised file-read/JSON-parse cases, not every process-command failure. The same command's scenario-validation control already returns a canonical error. No successful capture workflow, data loss, or security boundary failure was demonstrated; broader platform coverage was not tested. ### REA version 6.7.0; source commit `074768901f3cdc8205b61773fb1faf6f6c7b3ca8`, using its prebuilt runtime. Latest published release checked: `rea-agents-6.7.0`. ### Runtime and platform Node.js v26.12.0; Darwin, arm64. No Hopper/Ghidra provider was involved. ### Target and artifact context Local process-scenario/capture JSON input files: absent files, `not-json`, and an empty object control. No executable target or external API. ### Interface CLI ### Earliest failure stage Transport or result projection ### Relevant output or evidence Observed affected payload shape (message summarized to omit input paths): ```json {"error":"Process command failed","category":"invalid_input","message":"<file-read or invalid-JSON diagnostic>"} ``` The messages identify ENOENT for missing files or invalid UTF-8 JSON for the malformed file. The full-output case has `ok: false` and the same three-field object under `error`. Exported-schema validation from `dist/contracts/errorSchemas.js` rejected all four affected payloads, including after stripping their string label, while accepting both controls as described above. Source-derived corroboration at the tested revision: `src/application/process/ProcessCli.ts:223-246` translates these file failures into `ProcessCliFailure`; `:264-272` projects only the three observed fields. The typed-error branch at `:258-261` retains canonical fields. `src/cli/processCommands.ts:19-55` registers both commands. Existing `tests/boundary/filesystem/processCliFileInput.test.ts:142-186` asserts the three-field file failures; the verifier inspected that test but did not execute it. ### Typed outcome or recovery expected Keep exit 1 and actionable cause text. Ordinary JSON errors should pass the canonical labeled-envelope schema (or the strict projection when unlabeled). The full-output `error` member should pass the strict projection schema. Keep both controls passing without relaxing the schemas. These are proposed restoration checks, not an observed fix. ### Analysis or suspected cause Source-derived: the local `ProcessCliFailure` projection bypasses the canonical typed-error projection. This explains why file-read/JSON-parse failures differ from the valid-JSON scenario-validation control. ### Additional context Prepared with AI assistance and independently reproduced. No repair, full test suite, or real-provider test was performed. NOT_ENOUGH_INFO: no last-known-good version was tested. Before submission, upstream `main` was fetched at `d532b18123916a9e88f98c7880ba4f984e23d715`; no commits since the tested baseline changed the cited contract, command registration, process projection, or CLI logging files. Searches covered open and closed issues and PRs. Related reports #155 and PRs #107, #1080, and #1510 concern different error behavior and do not report these missing canonical fields.

bsakaguchi closed this issue

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

bsakaguchi commented

2026-10-31 00:38:35 +00:00

Author

Owner

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

Thanks, coygeek, for the four cases and two controls. From reading main at 01788bac8, not a run: this looks fixed. Commit 1629266e3c on 2026-10-21 names this issue. It also reworked src/application/process/ProcessCli.ts. Its test, tests/boundary/filesystem/processCliFileInput.test.ts:295-335, now expects code invalid_request, retryable false and a remediation action. That holds for both the missing file and the malformed JSON. It also checks the CLI envelope schema. Also, #5399 is the same gap in import-reference-source and is not covered by that commit. Closing is the maintainers' call.

🤖 Written with Claude Code (Fable 5.1, verified by Opus 5.5), posted with my OK 🦊

@CassieFox23 commented on GitHub (Oct 21, 2026): Thanks, coygeek, for the four cases and two controls. From reading main at 01788bac8, not a run: this looks fixed. Commit 1629266e3c on 2026-10-21 names this issue. It also reworked `src/application/process/ProcessCli.ts`. Its test, `tests/boundary/filesystem/processCliFileInput.test.ts:295-335`, now expects code `invalid_request`, `retryable` false and a remediation action. That holds for both the missing file and the malformed JSON. It also checks the CLI envelope schema. Also, #5399 is the same gap in `import-reference-source` and is not covered by that commit. Closing is the maintainers' call. 🤖 Written with Claude Code (Fable 5.1, verified by Opus 5.5), posted with my OK 🦊

bsakaguchi commented

2026-10-31 00:38:35 +00:00

Author

Owner

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

Closing as fixed on main by github.com/morluto/rea@1629266e3c, retained at 67a6477f01.

Process CLI file-input failures now use canonical AnalysisInputError and shared error projection. Regressions cover missing/malformed inputs, comparison, required machine-readable fields, and full-output error schemas. The separately reported #5399 is outside this closure.

This closure follows current-main producer and regression source inspection and the existing issue evidence. Tests and runtime reproductions were not rerun in this audit; no additional platform/provider coverage is implied.

@morluto commented on GitHub (Oct 21, 2026): Closing as fixed on main by https://github.com/morluto/rea/commit/1629266e3c08c90fed6bba5383528af7986a12b7, retained at 67a6477f011ae358fc333e5a6e26c86d932654ed. Process CLI file-input failures now use canonical AnalysisInputError and shared error projection. Regressions cover missing/malformed inputs, comparison, required machine-readable fields, and full-output error schemas. The separately reported #5399 is outside this closure. This closure follows current-main producer and regression source inspection and the existing issue evidence. Tests and runtime reproductions were not rerun in this audit; no additional platform/provider coverage is implied.

bsakaguchi referenced this issue

2026-10-31 01:08:38 +00:00

[PR #3267] [CLOSED] fix(rea): bound oversized SDK validation errors #5686

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

No description provided.

Rows
Columns