morluto/rea

Fork 0

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

[GH-ISSUE #8033] analyze-javascript-application: deterministic hang on ~490-byte ESM input (parse phase); --analysis-timeout-ms inconsistently enforced #4660

New issue

Open

opened 2026-10-31 00:52:08 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

2026-10-31 00:52:08 +00:00

Owner

Originally created by @Rubinho82 on GitHub (Oct 29, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8033

Summary

rea analyze-javascript-application never completes on a small, valid ESM source (~490 bytes): the run sticks in the parse_javascript_source phase ("Parsing and projecting part.mjs (1/1)", sequence 4) until killed externally. Deterministic across many runs.

A second issue in the same area: --analysis-timeout-ms enforcement is inconsistent — sometimes the operation exits 1 at ~deadline with Analysis operation timed out, other times (same settings, same input shape) it never self-terminates and needs an external SIGTERM well past the deadline.

Repro environment

rea-agents 6.5.0 (npm CLI, rea.mjs), host win32 x64, Node.js v24.22.1
NODE_OPTIONS=--max-old-space-size=8192 (does not matter; heap is not the constraint)

rea analyze-javascript-application <dir> --analysis-timeout-ms 120000 --format json

where <dir> contains exactly one file part.mjs with the source below.

Repro source

Self-written reduction (491 bytes, node --check passes; identifiers and strings differ from the original — structure preserved). A variant with a multiline template literal also hangs.

export function guard({limit, aborted, turnAborted, readState, writeState, repo}) {
  if (ready() || aborted || online() && turnAborted) return false;
  let jobs = Object.values(readState().tasks ?? {});
  if (!within(limit, jobs)) return false;
  return log(`guard halt: spend ${spent()} reached ${limit}; stopping workers`), process.stderr.write(`Budget ($${spent().toFixed(2)} of ${limit})`), emit("guard_halt"), sync({registry: build(readState, writeState), writeState, repo}), true;
}

Construct mix suspected of mattering: destructured object parameter, unresolved external calls (ready/within/log/…), ||/&& mix, ?? inside Object.values(...), template literal with .toFixed(2) inside a comma-expression return chain. I did not ablate further than these two variants.

Observed behavior

Stuck at "phase":"parse_javascript_source" → "Parsing and projecting part.mjs (1/1)" → sequence 4, indefinitely.
Timeout enforcement varies: with --analysis-timeout-ms 150000 some runs exited 1 at ~151s with Analysis operation timed out after 150000ms; other runs with identical flags/input never exited and were killed by a watchdog at 170–200s (process still alive, no exit).
--max-semantic-nodes 500 --max-semantic-nodes-per-file 200 do not help — the hang precedes semantic node retention.
Trigger is the function itself: removing it (or analyzing other slices of the same original source) completes in 1–6s. A 492-byte file containing only that function hangs; the same corpus without it passes.
Detection caveat for testers: the same slice written as .js without a leading import/export can pass in seconds — Node's module detection treats it as CJS and REA appears to take a shallower path. Use .mjs (or a leading import/export) to reproduce reliably. This made the hang look content-dependent before it was isolated to one function.

Impact

In a corpus of 2,526 extracted sources, this one file aborts any part that reaches it (remaining sources were not analyzed), forcing split-and-retry runs to reach full coverage. A single pathological input silently reduces coverage of the whole analyze-javascript-application invocation.

Notes

Happy to share the original file's SHA-256 / structural stats privately (the original is extracted from a commercial product, so it can't be attached here).
Would a per-file wall-clock hard-kill (separate from --analysis-timeout-ms) or a phase-level watchdog be acceptable as a mitigation while the root cause is investigated?

Originally created by @Rubinho82 on GitHub (Oct 29, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8033 ## Summary `rea analyze-javascript-application` never completes on a small, valid ESM source (~490 bytes): the run sticks in the `parse_javascript_source` phase (`"Parsing and projecting part.mjs (1/1)"`, sequence 4) until killed externally. Deterministic across many runs. A second issue in the same area: `--analysis-timeout-ms` enforcement is **inconsistent** — sometimes the operation exits 1 at ~deadline with `Analysis operation timed out`, other times (same settings, same input shape) it never self-terminates and needs an external SIGTERM well past the deadline. ## Repro environment - `rea-agents` 6.5.0 (npm CLI, `rea.mjs`), host `win32 x64`, Node.js v24.22.1 - `NODE_OPTIONS=--max-old-space-size=8192` (does not matter; heap is not the constraint) ```bash rea analyze-javascript-application <dir> --analysis-timeout-ms 120000 --format json ``` where `<dir>` contains exactly one file `part.mjs` with the source below. ## Repro source Self-written reduction (491 bytes, `node --check` passes; identifiers and strings differ from the original — structure preserved). A variant with a multiline template literal also hangs. ```js export function guard({limit, aborted, turnAborted, readState, writeState, repo}) { if (ready() || aborted || online() && turnAborted) return false; let jobs = Object.values(readState().tasks ?? {}); if (!within(limit, jobs)) return false; return log(`guard halt: spend ${spent()} reached ${limit}; stopping workers`), process.stderr.write(`Budget ($${spent().toFixed(2)} of ${limit})`), emit("guard_halt"), sync({registry: build(readState, writeState), writeState, repo}), true; } ``` Construct mix suspected of mattering: destructured object parameter, unresolved external calls (`ready`/`within`/`log`/…), `||`/`&&` mix, `??` inside `Object.values(...)`, template literal with `.toFixed(2)` inside a comma-expression `return` chain. I did not ablate further than these two variants. ## Observed behavior 1. Stuck at `"phase":"parse_javascript_source"` → `"Parsing and projecting part.mjs (1/1)"` → sequence 4, indefinitely. 2. Timeout enforcement varies: with `--analysis-timeout-ms 150000` some runs exited 1 at ~151s with `Analysis operation timed out after 150000ms`; other runs with identical flags/input never exited and were killed by a watchdog at 170–200s (process still alive, no exit). 3. `--max-semantic-nodes 500 --max-semantic-nodes-per-file 200` do **not** help — the hang precedes semantic node retention. 4. Trigger is the function itself: removing it (or analyzing other slices of the same original source) completes in 1–6s. A 492-byte file containing only that function hangs; the same corpus without it passes. 5. Detection caveat for testers: the same slice written as `.js` **without** a leading `import`/`export` can pass in seconds — Node's module detection treats it as CJS and REA appears to take a shallower path. Use `.mjs` (or a leading import/export) to reproduce reliably. This made the hang look content-dependent before it was isolated to one function. ## Impact In a corpus of 2,526 extracted sources, this one file aborts any part that reaches it (`remaining sources were not analyzed`), forcing split-and-retry runs to reach full coverage. A single pathological input silently reduces coverage of the whole `analyze-javascript-application` invocation. ## Notes - Happy to share the original file's SHA-256 / structural stats privately (the original is extracted from a commercial product, so it can't be attached here). - Would a per-file wall-clock hard-kill (separate from `--analysis-timeout-ms`) or a phase-level watchdog be acceptable as a mitigation while the root cause is investigated?

bsakaguchi commented

2026-10-31 00:52:09 +00:00

Author

Owner

@amarthya-14 commented on GitHub (Oct 29, 2026):

I tried to reproduce this on macOS (arm64, Node 24.22.2) with the 490-byte part.mjs from the report as the only file in the selected directory, running rea analyze-javascript-application <dir> --analysis-timeout-ms 20000 --format json:

rea-agents@6.5.0: exit 0 after 38 s (most of that was first-run setup), Evidence status complete.
rea-agents@6.8.0: exit 0 after 4 s, Evidence status complete.
Running the worker's per-file steps directly on main (bf115be), meaning parseJavaScriptSource, analyzeParsedJavaScriptStaticSourceSteps and analyzeParsedJavaScriptSemanticsSteps, finished in about 30 ms.

So this reduction does not hang on macOS. The hang may depend on the Windows host (worker process or pipe handling) or on something in the original file that the reduction doesn't keep. I couldn't test on Windows.

@amarthya-14 commented on GitHub (Oct 29, 2026): I tried to reproduce this on macOS (arm64, Node 24.22.2) with the 490-byte `part.mjs` from the report as the only file in the selected directory, running `rea analyze-javascript-application <dir> --analysis-timeout-ms 20000 --format json`: - `rea-agents@6.5.0`: exit 0 after 38 s (most of that was first-run setup), Evidence status `complete`. - `rea-agents@6.8.0`: exit 0 after 4 s, Evidence status `complete`. - Running the worker's per-file steps directly on `main` (bf115be), meaning `parseJavaScriptSource`, `analyzeParsedJavaScriptStaticSourceSteps` and `analyzeParsedJavaScriptSemanticsSteps`, finished in about 30 ms. So this reduction does not hang on macOS. The hang may depend on the Windows host (worker process or pipe handling) or on something in the original file that the reduction doesn't keep. I couldn't test on Windows.

bsakaguchi commented

2026-10-31 00:52:09 +00:00

Author

Owner

@XiaoBinGan commented on GitHub (Oct 30, 2026):

I could not reproduce this on Windows either, and I think the report predates the fix.

Host: Windows x64, Node v24.22.1, current main (317bf3fe2), running the 490-byte part.mjs from the report as the only file in the directory:

node scripts/rea.mjs analyze-javascript-application <dir> --analysis-timeout-ms 60000 --format json

The run completed and advanced through every phase the report says it sticks on:

parse_javascript_sources       sequence 3
parse_javascript_source        sequence 4   ("Parsing and projecting part.mjs (1/1)")
javascript_worker_parse        sequence 5
javascript_worker_static       sequence 6
javascript_worker_semantic     sequence 7
javascript_worker_projection   sequence 8
javascript_worker_transfer     sequence 9
build_javascript_application_graph  sequence 10
seal_javascript_application_graph   sequence 11
build_javascript_semantic_graph

No external kill was needed, and the timeout path was not exercised.

I also ran the worker's per-file steps directly on main — parseJavaScriptSource, analyzeParsedJavaScriptStaticSourceSteps, analyzeParsedJavaScriptSemanticsSteps, projectJavaScriptModuleSemantics and measureJavaScriptModuleTransfer — at 3 ms / 37 ms / 45 ms / 0 ms / 0–10 ms respectively, so the per-file work is not pathological for this input.

That matches the macOS result in the comment above: the reduction does not hang on 6.8.0. Two possibilities remain for the original report: the hang was specific to 6.5.0 and was already fixed, or it depends on something in the original file that the reduction does not preserve. If the reporter can still reproduce on 6.8.0, a copy of the original file (or its structural stats) would be needed to go further.

The separate --analysis-timeout-ms point may still be worth keeping open: I did not exercise the deadline path here, so I can neither confirm nor refute the inconsistent enforcement.

@XiaoBinGan commented on GitHub (Oct 30, 2026): I could not reproduce this on Windows either, and I think the report predates the fix. Host: Windows x64, Node v24.22.1, current `main` (`317bf3fe2`), running the 490-byte `part.mjs` from the report as the only file in the directory: ``` node scripts/rea.mjs analyze-javascript-application <dir> --analysis-timeout-ms 60000 --format json ``` The run completed and advanced through every phase the report says it sticks on: ``` parse_javascript_sources sequence 3 parse_javascript_source sequence 4 ("Parsing and projecting part.mjs (1/1)") javascript_worker_parse sequence 5 javascript_worker_static sequence 6 javascript_worker_semantic sequence 7 javascript_worker_projection sequence 8 javascript_worker_transfer sequence 9 build_javascript_application_graph sequence 10 seal_javascript_application_graph sequence 11 build_javascript_semantic_graph ``` No external kill was needed, and the timeout path was not exercised. I also ran the worker's per-file steps directly on `main` — `parseJavaScriptSource`, `analyzeParsedJavaScriptStaticSourceSteps`, `analyzeParsedJavaScriptSemanticsSteps`, `projectJavaScriptModuleSemantics` and `measureJavaScriptModuleTransfer` — at 3 ms / 37 ms / 45 ms / 0 ms / 0–10 ms respectively, so the per-file work is not pathological for this input. That matches the macOS result in the comment above: the reduction does not hang on 6.8.0. Two possibilities remain for the original report: the hang was specific to 6.5.0 and was already fixed, or it depends on something in the original file that the reduction does not preserve. If the reporter can still reproduce on 6.8.0, a copy of the original file (or its structural stats) would be needed to go further. The separate `--analysis-timeout-ms` point may still be worth keeping open: I did not exercise the deadline path here, so I can neither confirm nor refute the inconsistent enforcement.

bsakaguchi commented

2026-10-31 00:52:09 +00:00

Author

Owner

@amarthya-14 commented on GitHub (Oct 30, 2026):

On the --analysis-timeout-ms part: I found one Windows-only mechanism that matches the "stuck at sequence 4" symptom. I have not reproduced it on Windows.

In WindowsOwnedProcess.#poll, if the native process_poll call throws, the catch records the failure and emits error but never schedules another poll. From then on the parent receives no worker output and never observes the exit. JavaScriptAnalysisWorker.#observeProcessDiagnostic ignores error, so the parent waits in #next until the per-source deadline, and cleanup after the deadline relies on the same poll path.

Using the existing native-authority double, a failed first poll followed by a poll carrying a stdout frame gives exactly one process_poll call over 60 s of fake time: no output and no exit.

I opened #8163 to keep polling after a failure (250 ms backoff) with a regression test. It does not show why process_poll would fail on the reporter's host, or that this is the cause of the original hang.

@amarthya-14 commented on GitHub (Oct 30, 2026): On the `--analysis-timeout-ms` part: I found one Windows-only mechanism that matches the "stuck at sequence 4" symptom. I have not reproduced it on Windows. In `WindowsOwnedProcess.#poll`, if the native `process_poll` call throws, the `catch` records the failure and emits `error` but never schedules another poll. From then on the parent receives no worker output and never observes the exit. `JavaScriptAnalysisWorker.#observeProcessDiagnostic` ignores `error`, so the parent waits in `#next` until the per-source deadline, and cleanup after the deadline relies on the same poll path. Using the existing native-authority double, a failed first poll followed by a poll carrying a stdout frame gives exactly one `process_poll` call over 60 s of fake time: no output and no exit. I opened #8163 to keep polling after a failure (250 ms backoff) with a regression test. It does not show why `process_poll` would fail on the reporter's host, or that this is the cause of the original hang.

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

No description provided.

Rows
Columns