morluto/rea

Fork 0

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

[GH-ISSUE #2272] [Bug] capture_electron_scenario reports every unresolvable path as application_path/invalid_format and drops the cause #752

New issue

Closed

opened 2026-10-15 18:27:59 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-15 18:27:59 +00:00

Owner

Originally created by @BeLit-Development-2 on GitHub (Oct 12, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/2272

Before submitting

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

Area

MCP or agent integration

Observed behavior

When any of the three filesystem inputs of capture_electron_scenario (executable_path, application_path, application_root) does not resolve, REA returns the same validation issue regardless of which one is missing:

{"path":["application_path"],"reason":"invalid_format","message":"Electron executable, application, and root must resolve to existing paths"}

When the executable is missing and the application exists, the error blames application_path.
When application_root is missing, the error also blames application_path.
In every case the reason is invalid_format, although the input is well-formed and the problem is that it does not exist.
The underlying cause (which path, which errno) is not surfaced, so neither a human nor an agent can tell what to fix. An agent following the issues[].path pointer will "correct" an application path that was never wrong.

The same happens over MCP and the CLI. Other commands already report the precise path and errno. For example, inspect-managed-artifact on a missing file says Cannot open artifact: target does not exist … ENOENT: no such file or directory, access '<path>'.

Reproduction

Create C:\repro\app\package.json ({"name":"x","main":"main.js"}), an empty C:\repro\app\main.js, and any existing file C:\repro\file.txt.
Run each of these (CLI shown; the MCP capture_electron_scenario tool returns the same issue), using BOM-free JSON files:

Case	Input	Expected `issues[0].path`	Actual
A	`{"executable_path":"C:\\repro\\missing\\electron.exe","application_path":"C:\\repro\\app","actions":[]}`	`["executable_path"]`	`["application_path"]`
B	`{"executable_path":"C:\\repro\\file.txt","application_path":"C:\\repro\\missing-app","actions":[]}`	`["application_path"]`	`["application_path"]` (correct only by coincidence)
C	`{"executable_path":"C:\\repro\\file.txt","application_path":"C:\\repro\\app","application_root":"C:\\repro\\missing-root","actions":[]}`	`["application_root"]`	`["application_path"]`

rea capture-electron-scenario C:\repro\caseA.json --format json → exit 1, identical details.issues for all three cases.

(Cases B and C fail validation before any launch, so they do not trigger #2269. Do not make case A's executable an existing non-executable file, because that path reaches the launch and crashes the process per #2269.)

Expected behavior

One issue per unresolvable input, pointing at the field that actually failed, with a not-found style reason (e.g. not_found / target_unavailable) and the resolved path or errno in the message. For example:

{"path":["executable_path"],"reason":"not_found","message":"Electron executable does not exist: C:\\repro\\missing\\electron.exe (ENOENT)"}

If several inputs are missing, all of them are reported.

Impact and scope

Misdirects remediation for both people and agents. The structured issues[].path is exactly what agent clients use to decide which argument to change.
Only the path-canonicalization step of capture_electron_scenario is affected. Schema validation (relative paths, action discriminators) already reports precise paths.
No effect on evidence integrity or process isolation.

REA version

6.4.0 (npm, global install)

Runtime and platform

Node 24.20.0; Windows 11 x64 (10.0.26300)

Target and artifact context

Not applicable (input validation; no Electron runtime involved)

Interface

MCP (also reproduces via CLI)

Earliest failure stage

Request parsing or validation

Relevant output or evidence

=== A_missing_executable  exit=1
{"error":"Electron analysis failed","code":"invalid_request","category":"invalid_input",
 "message":"Analysis input is invalid. Check the arguments and try again.","retryable":true,
 "remediation":{"action":"Correct the listed arguments and retry."},
 "details":{"operation":"capture_electron_scenario","issues":[{"path":["application_path"],
 "reason":"invalid_format","message":"Electron executable, application, and root must resolve to existing paths"}]}}
=== B_missing_application  exit=1   (identical details.issues)
=== C_missing_root         exit=1   (identical details.issues)

Typed outcome or recovery expected

invalid_request (or target_unavailable) whose issues[] names the failing field(s) and carries the errno/path, so the caller can correct the right argument on the first retry. Optionally retryable: false, since retrying identical input cannot succeed.

Analysis or suspected cause

Source-derived: dist/application/javascript/ElectronActiveObservationService.js, canonicalizeInput (lines 9–37). It calls realpath on executable_path and application_path together (Promise.all), then on application_root, inside one try. The single catch returns a hard-coded issue { path: ["application_path"], reason: "invalid_format", … }, and the cause is attached only to the error object, not to the issue. Canonicalizing each field separately (or mapping the rejected realpath back to its field) and including cause.code / cause.path in the issue message would fix it.

The same step only checks existence. Checking that executable_path is a launchable file would also prevent #2269.

Additional context

Split out from #2269, which is the crash when the executable exists but is not launchable.
Found during a ground-truth test run of REA 6.4.0 on Windows.

Originally created by @BeLit-Development-2 on GitHub (Oct 12, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2272 ### 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 MCP or agent integration ### Observed behavior When any of the three filesystem inputs of `capture_electron_scenario` (`executable_path`, `application_path`, `application_root`) does not resolve, REA returns the same validation issue regardless of which one is missing: ```json {"path":["application_path"],"reason":"invalid_format","message":"Electron executable, application, and root must resolve to existing paths"} ``` - When the **executable** is missing and the application exists, the error blames `application_path`. - When `application_root` is missing, the error also blames `application_path`. - In every case the reason is `invalid_format`, although the input is well-formed and the problem is that it does not exist. - The underlying cause (which path, which errno) is not surfaced, so neither a human nor an agent can tell what to fix. An agent following the `issues[].path` pointer will "correct" an application path that was never wrong. The same happens over MCP and the CLI. Other commands already report the precise path and errno. For example, `inspect-managed-artifact` on a missing file says `Cannot open artifact: target does not exist … ENOENT: no such file or directory, access '<path>'`. ### Reproduction 1. Create `C:\repro\app\package.json` (`{"name":"x","main":"main.js"}`), an empty `C:\repro\app\main.js`, and any existing file `C:\repro\file.txt`. 2. Run each of these (CLI shown; the MCP `capture_electron_scenario` tool returns the same issue), using BOM-free JSON files: | Case | Input | Expected `issues[0].path` | Actual | |---|---|---|---| | A | `{"executable_path":"C:\\repro\\missing\\electron.exe","application_path":"C:\\repro\\app","actions":[]}` | `["executable_path"]` | `["application_path"]` | | B | `{"executable_path":"C:\\repro\\file.txt","application_path":"C:\\repro\\missing-app","actions":[]}` | `["application_path"]` | `["application_path"]` (correct only by coincidence) | | C | `{"executable_path":"C:\\repro\\file.txt","application_path":"C:\\repro\\app","application_root":"C:\\repro\\missing-root","actions":[]}` | `["application_root"]` | `["application_path"]` | `rea capture-electron-scenario C:\repro\caseA.json --format json` → exit 1, identical `details.issues` for all three cases. (Cases B and C fail validation before any launch, so they do not trigger #2269. Do not make case A's executable an existing non-executable file, because that path reaches the launch and crashes the process per #2269.) ### Expected behavior One issue per unresolvable input, pointing at the field that actually failed, with a not-found style reason (e.g. `not_found` / `target_unavailable`) and the resolved path or errno in the message. For example: ```json {"path":["executable_path"],"reason":"not_found","message":"Electron executable does not exist: C:\\repro\\missing\\electron.exe (ENOENT)"} ``` If several inputs are missing, all of them are reported. ### Impact and scope - Misdirects remediation for both people and agents. The structured `issues[].path` is exactly what agent clients use to decide which argument to change. - Only the path-canonicalization step of `capture_electron_scenario` is affected. Schema validation (relative paths, action discriminators) already reports precise paths. - No effect on evidence integrity or process isolation. ### REA version 6.4.0 (npm, global install) ### Runtime and platform Node 24.20.0; Windows 11 x64 (10.0.26300) ### Target and artifact context Not applicable (input validation; no Electron runtime involved) ### Interface MCP (also reproduces via CLI) ### Earliest failure stage Request parsing or validation ### Relevant output or evidence ```text === A_missing_executable exit=1 {"error":"Electron analysis failed","code":"invalid_request","category":"invalid_input", "message":"Analysis input is invalid. Check the arguments and try again.","retryable":true, "remediation":{"action":"Correct the listed arguments and retry."}, "details":{"operation":"capture_electron_scenario","issues":[{"path":["application_path"], "reason":"invalid_format","message":"Electron executable, application, and root must resolve to existing paths"}]}} === B_missing_application exit=1 (identical details.issues) === C_missing_root exit=1 (identical details.issues) ``` ### Typed outcome or recovery expected `invalid_request` (or `target_unavailable`) whose `issues[]` names the failing field(s) and carries the errno/path, so the caller can correct the right argument on the first retry. Optionally `retryable: false`, since retrying identical input cannot succeed. ### Analysis or suspected cause *Source-derived:* `dist/application/javascript/ElectronActiveObservationService.js`, `canonicalizeInput` (lines 9–37). It calls `realpath` on `executable_path` and `application_path` together (`Promise.all`), then on `application_root`, inside one `try`. The single `catch` returns a hard-coded issue `{ path: ["application_path"], reason: "invalid_format", … }`, and the `cause` is attached only to the error object, not to the issue. Canonicalizing each field separately (or mapping the rejected `realpath` back to its field) and including `cause.code` / `cause.path` in the issue message would fix it. The same step only checks existence. Checking that `executable_path` is a launchable file would also prevent #2269. ### Additional context - Split out from #2269, which is the crash when the executable exists but is not launchable. - Found during a ground-truth test run of REA 6.4.0 on Windows.

bsakaguchi

2026-10-15 18:27:59 +00:00

closed this issue
added the
area: runtime

bug
labels

bsakaguchi commented

2026-10-15 18:28:00 +00:00

Author

Owner

@harshdazz commented on GitHub (Oct 12, 2026):

Hi! I'd like to pick this one up.

Checked on the latest main and canonicalizeInput in ElectronActiveObservationService.ts still runs all three realpath calls inside one try, so the catch always points at application_path.

I'll resolve executable_path, application_path and application_root separately and return one issue for each path that fails, on the right field, with the error code (e.g. ENOENT) in the message. For the reason I'd keep the existing invalid_value rather than add a new not_found to AnalysisInputIssue, since those reasons are shared by every tool.

There's no test for this service yet, so I'll add one next to it covering the three cases from the issue, plus more than one path missing at once. I'll leave the launch crash in #2269 for a separate fix.

Let me know if you'd prefer a different approach.

@harshdazz commented on GitHub (Oct 12, 2026): Hi! I'd like to pick this one up. Checked on the latest `main` and `canonicalizeInput` in `ElectronActiveObservationService.ts` still runs all three `realpath` calls inside one `try`, so the `catch` always points at `application_path`. I'll resolve `executable_path`, `application_path` and `application_root` separately and return one issue for each path that fails, on the right field, with the error code (e.g. `ENOENT`) in the message. For the reason I'd keep the existing `invalid_value` rather than add a new `not_found` to `AnalysisInputIssue`, since those reasons are shared by every tool. There's no test for this service yet, so I'll add one next to it covering the three cases from the issue, plus more than one path missing at once. I'll leave the launch crash in #2269 for a separate fix. Let me know if you'd prefer a different approach.

bsakaguchi commented

2026-10-15 18:28:00 +00:00

Author

Owner

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

TL;DR: This issue is closed. Main fixed the wrong-field error in b7169c8b7. I tested the fix on Linux, and each missing path now gets its own issue on the right field.

This is a record, not a request to reopen. The fix landed on main at 20:12 UTC on 2026-10-12 as a direct commit.

What I ran

I built main just before the fix (049132ab4) and main with the fix (4dd44ddf1). I ran 22 inputs through the compiled CLI on both. Every input had at least one path that does not resolve, so nothing could launch. No Electron app started and no window opened.

Key repro, case A from the issue, adapted to Linux (the app folder holds a package.json and an empty main.js):

rea capture-electron-scenario '{"executable_path":"/tmp/pr2279/fix/missing-electron","application_path":"/tmp/pr2279/fix/app","actions":[]}' --format json

Input	Before the fix (`049132ab4`)	With the fix (`4dd44ddf1`)
Executable missing	one issue on `application_path`, `invalid_format`	one issue on `executable_path`, `invalid_value`, ENOENT
Application missing	one issue on `application_path`, `invalid_format`	one issue on `application_path`, `invalid_value`, ENOENT
Root missing	one issue on `application_path`, `invalid_format`	one issue on `application_root`, `invalid_value`, ENOENT
All three missing	one issue on `application_path`, `invalid_format`	three issues, in field order
Blocked folder, file used as a folder, link loop	one issue on `application_path`, `invalid_format`	one issue on the failing field, with its error code

All 22 inputs behaved this way, with exit code 1 each time. Each error code and path in a message matched its input. The same held on Node 22, 24 and 26, and main's new test passes with the fix and fails before it.

Not run

A real Electron launch, or any input where every path resolves. That would start a program and open a window.
An existing file that is not an executable, used as the executable. That is the separate crash in #2269, which this commit does not address.
Windows. The issue came from Windows 11. I ran Linux only.

Thanks, BeLit-Development-2, for a clear report with a good repro table in it. Thanks, morluto, for the fix.

The 22 inputs

Executable missing, root left out or given (2)
Application missing, root left out or given (2)
Root missing (1)
All three missing (1)
Executable and application missing, root left out (1)
Executable and application missing, root given (1)
Executable and root missing (1)
Application and root missing (1)
Permission denied (EACCES) on the executable, the application, the root (3)
Not a directory (ENOTDIR), on each of the three fields (3)
Symlink loop (ELOOP), on each of the three fields (3)
Permission denied on the executable, not a directory on the application, symlink loop on the root (1)
A dangling symlink as the executable (1)
A missing file under a symlinked directory as the executable (1). The message shows the path as given, not the target of the link.

Node 22, 24 and 26

Check	Node 22.23.1	Node 24.18.0	Node 26.11.1
22 inputs with the fix: one issue per failing field	yes	yes	yes
New test `electronInvalidPaths` with the fix	passes	passes	passes
Same test before the fix	fails	fails	fails

Raw output, all three paths missing

Before the fix (049132ab4):

{"path":["application_path"],"reason":"invalid_format","message":"Electron executable, application, and root must resolve to existing paths"}

With the fix (4dd44ddf1):

{"path":["executable_path"],"reason":"invalid_value","message":"Cannot resolve executable_path /tmp/pr2279/fix/missing-electron: ENOENT: no such file or directory, realpath '/tmp/pr2279/fix/missing-electron'"}
{"path":["application_path"],"reason":"invalid_value","message":"Cannot resolve application_path /tmp/pr2279/fix/missing-app: ENOENT: no such file or directory, realpath '/tmp/pr2279/fix/missing-app'"}
{"path":["application_root"],"reason":"invalid_value","message":"Cannot resolve application_root /tmp/pr2279/fix/missing-root: ENOENT: no such file or directory, realpath '/tmp/pr2279/fix/missing-root'"}

Commands

npm ci && npm run build && npm run test:prepare          # in each tree, Node 24
node <tree>/scripts/rea.mjs capture-electron-scenario '<json>' --format json     # 22 inputs, Node 22, 24 and 26
node scripts/run-development-tests.mjs focused tests/acceptance/applications/electronInvalidPaths.test.ts   # what npm run test:focused runs; Node 22, 24 and 26

Before each run I checked that at least one of the three paths fails to resolve. During each CLI run I watched /proc every 20 ms for new processes under the CLI. There were none.

Test setup

Box: Nobara 44 (Fedora 44 base), Linux 7.2.9
CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads
RAM: 32 GB DDR4-3600
Node: 22.23.1, 24.18.0, 26.11.1
Before / with the fix: 049132ab4 / 4dd44ddf1

🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊

@CassieFox23 commented on GitHub (Oct 12, 2026): **TL;DR:** This issue is closed. Main fixed the wrong-field error in b7169c8b7. I tested the fix on Linux, and each missing path now gets its own issue on the right field. This is a record, not a request to reopen. The fix landed on main at 20:12 UTC on 2026-10-12 as a direct commit. ### What I ran I built main just before the fix (049132ab4) and main with the fix (4dd44ddf1). I ran 22 inputs through the compiled CLI on both. Every input had at least one path that does not resolve, so nothing could launch. No Electron app started and no window opened. Key repro, case A from the issue, adapted to Linux (the app folder holds a `package.json` and an empty `main.js`): ``` rea capture-electron-scenario '{"executable_path":"/tmp/pr2279/fix/missing-electron","application_path":"/tmp/pr2279/fix/app","actions":[]}' --format json ``` | Input | Before the fix (049132ab4) | With the fix (4dd44ddf1) | | --- | --- | --- | | Executable missing | one issue on `application_path`, `invalid_format` | one issue on `executable_path`, `invalid_value`, ENOENT | | Application missing | one issue on `application_path`, `invalid_format` | one issue on `application_path`, `invalid_value`, ENOENT | | Root missing | one issue on `application_path`, `invalid_format` | one issue on `application_root`, `invalid_value`, ENOENT | | All three missing | one issue on `application_path`, `invalid_format` | three issues, in field order | | Blocked folder, file used as a folder, link loop | one issue on `application_path`, `invalid_format` | one issue on the failing field, with its error code | All 22 inputs behaved this way, with exit code 1 each time. Each error code and path in a message matched its input. The same held on Node 22, 24 and 26, and main's new test passes with the fix and fails before it. ### Not run - A real Electron launch, or any input where every path resolves. That would start a program and open a window. - An existing file that is not an executable, used as the executable. That is the separate crash in #2269, which this commit does not address. - Windows. The issue came from Windows 11. I ran Linux only. Thanks, BeLit-Development-2, for a clear report with a good repro table in it. Thanks, morluto, for the fix. <details> <summary>The 22 inputs</summary> - Executable missing, root left out or given (2) - Application missing, root left out or given (2) - Root missing (1) - All three missing (1) - Executable and application missing, root left out (1) - Executable and application missing, root given (1) - Executable and root missing (1) - Application and root missing (1) - Permission denied (`EACCES`) on the executable, the application, the root (3) - Not a directory (`ENOTDIR`), on each of the three fields (3) - Symlink loop (`ELOOP`), on each of the three fields (3) - Permission denied on the executable, not a directory on the application, symlink loop on the root (1) - A dangling symlink as the executable (1) - A missing file under a symlinked directory as the executable (1). The message shows the path as given, not the target of the link. </details> <details> <summary>Node 22, 24 and 26</summary> | Check | Node 22.23.1 | Node 24.18.0 | Node 26.11.1 | | --- | --- | --- | --- | | 22 inputs with the fix: one issue per failing field | yes | yes | yes | | New test `electronInvalidPaths` with the fix | passes | passes | passes | | Same test before the fix | fails | fails | fails | </details> <details> <summary>Raw output, all three paths missing</summary> Before the fix (049132ab4): ```json {"path":["application_path"],"reason":"invalid_format","message":"Electron executable, application, and root must resolve to existing paths"} ``` With the fix (4dd44ddf1): ```json {"path":["executable_path"],"reason":"invalid_value","message":"Cannot resolve executable_path /tmp/pr2279/fix/missing-electron: ENOENT: no such file or directory, realpath '/tmp/pr2279/fix/missing-electron'"} {"path":["application_path"],"reason":"invalid_value","message":"Cannot resolve application_path /tmp/pr2279/fix/missing-app: ENOENT: no such file or directory, realpath '/tmp/pr2279/fix/missing-app'"} {"path":["application_root"],"reason":"invalid_value","message":"Cannot resolve application_root /tmp/pr2279/fix/missing-root: ENOENT: no such file or directory, realpath '/tmp/pr2279/fix/missing-root'"} ``` </details> <details> <summary>Commands</summary> ``` npm ci && npm run build && npm run test:prepare # in each tree, Node 24 node <tree>/scripts/rea.mjs capture-electron-scenario '<json>' --format json # 22 inputs, Node 22, 24 and 26 node scripts/run-development-tests.mjs focused tests/acceptance/applications/electronInvalidPaths.test.ts # what npm run test:focused runs; Node 22, 24 and 26 ``` Before each run I checked that at least one of the three paths fails to resolve. During each CLI run I watched /proc every 20 ms for new processes under the CLI. There were none. </details> <details> <summary>Test setup</summary> - Box: Nobara 44 (Fedora 44 base), Linux 7.2.9 - CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads - RAM: 32 GB DDR4-3600 - Node: 22.23.1, 24.18.0, 26.11.1 - Before / with the fix: 049132ab4 / 4dd44ddf1 </details> 🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊

bsakaguchi referenced this issue

2026-10-15 18:28:29 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi referenced this issue

2026-10-16 21:15:45 +00:00

[PR #752] [MERGED] fix(javascript): keep mutated object initializer values unknown #2214

bsakaguchi referenced this issue

2026-10-16 21:16:27 +00:00

[PR #815] [MERGED] fix: integrate 24 reviewed browser/native/semantics corrections #2262

bsakaguchi referenced this issue

2026-10-16 21:16:30 +00:00

[PR #825] [MERGED] fix(browser): preserve form destinations and satisfies mutation uncertainty #2266