[GH-ISSUE #1847] [Bug] JavaScript semantic workers exhaust heap on modest generated wrapper files #622

Closed
opened 2026-10-15 18:26:43 +00:00 by bsakaguchi · 3 comments
Owner

Originally created by @N0zoM1z0 on GitHub (Oct 11, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1847

Before submitting

  • I searched open and closed issues and pull requests for related work.
  • I removed credentials, private paths, and sensitive target data.

Area

Evidence, artifacts, or reconstruction.

Observed behavior

Two inert generated JavaScript wrappers of 439,680 and 438,705 bytes parse successfully, but each owned worker exhausts its heap during semantic analysis. Summary output returns partial semantic coverage with no retained relations in the reported families.

Reproduction

  1. Place generated JavaScript wrappers with extensive nested function/object and binding structure in a selected directory.
  2. Call analyze_javascript_application with that directory, format=directory, detail=summary.
  3. Examine syntax coverage, semantic limitations and worker failure stage separately.

Expected behavior

Produce useful semantic evidence within the owned working-set limit, or a bounded useful partial result that accurately records examined coverage and unknowns. Preserve syntax evidence and MCP responsiveness.

Impact and scope

The parser visits 130,096 AST nodes without parse failures, but semantic evidence is unavailable. The main MCP process remains usable; this is worker heap exhaustion rather than a process-tree OOM.

REA version

Observed at source revision 97c0348e6bef62bb7183d52bcebea8299c5b3afe; current-main reproduction is part of the investigation.

Runtime and platform

Linux x86_64, Node.js 24.18.0. Heavy operations used a one-CPU, 3-GiB process-tree limit.

Interface

MCP; the shared CLI workflow should be verified where applicable.

Earliest failure stage

Native analysis or reconstruction; JavaScript semantic worker.

Relevant output or evidence

Resource constraint during analyze_javascript_application: Owned JavaScript worker exhausted its heap ... during semantic; semantic.truncated=true. The process-tree peak is 1,571,188,736 bytes, with zero OOM events.

Analysis or suspected cause

src/javascript/analysis/JavaScriptAnalysisWorker.ts reports the failure. Dominant allocations and semantic representation expansion are not profiled yet. Increasing the heap alone is not an established fix. Related but distinct: #1387 and #1065.

Originally created by @N0zoM1z0 on GitHub (Oct 11, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1847 ### Before submitting - [x] I searched open and closed issues and pull requests for related work. - [x] I removed credentials, private paths, and sensitive target data. ### Area Evidence, artifacts, or reconstruction. ### Observed behavior Two inert generated JavaScript wrappers of 439,680 and 438,705 bytes parse successfully, but each owned worker exhausts its heap during semantic analysis. Summary output returns partial semantic coverage with no retained relations in the reported families. ### Reproduction 1. Place generated JavaScript wrappers with extensive nested function/object and binding structure in a selected directory. 2. Call `analyze_javascript_application` with that directory, `format=directory`, `detail=summary`. 3. Examine syntax coverage, semantic limitations and worker failure stage separately. ### Expected behavior Produce useful semantic evidence within the owned working-set limit, or a bounded useful partial result that accurately records examined coverage and unknowns. Preserve syntax evidence and MCP responsiveness. ### Impact and scope The parser visits 130,096 AST nodes without parse failures, but semantic evidence is unavailable. The main MCP process remains usable; this is worker heap exhaustion rather than a process-tree OOM. ### REA version Observed at source revision `97c0348e6bef62bb7183d52bcebea8299c5b3afe`; current-main reproduction is part of the investigation. ### Runtime and platform Linux x86_64, Node.js 24.18.0. Heavy operations used a one-CPU, 3-GiB process-tree limit. ### Interface MCP; the shared CLI workflow should be verified where applicable. ### Earliest failure stage Native analysis or reconstruction; JavaScript semantic worker. ### Relevant output or evidence `Resource constraint during analyze_javascript_application: Owned JavaScript worker exhausted its heap ... during semantic`; `semantic.truncated=true`. The process-tree peak is 1,571,188,736 bytes, with zero OOM events. ### Analysis or suspected cause `src/javascript/analysis/JavaScriptAnalysisWorker.ts` reports the failure. Dominant allocations and semantic representation expansion are not profiled yet. Increasing the heap alone is not an established fix. Related but distinct: #1387 and #1065.
Author
Owner

@jimpablo commented on GitHub (Oct 11, 2026):

I'd like to work on this.

<!-- gh-comment-id:6111516650 --> @jimpablo commented on GitHub (Oct 11, 2026): I'd like to work on this.
Author
Owner

@N0zoM1z0 commented on GitHub (Oct 11, 2026):

Current-main investigation at 898d5096f94fe1ed3ea7d091455e638cc7d23bfd no longer reproduces the original worker-heap exhaustion on the same two generated wrappers (439,680 and 438,705 bytes). The worker heap setting remained 1,024 MiB. Both CLI analysis and a fresh stdio MCP session completed analysis without that worker failure; MCP remained responsive to a subsequent ping, and artifact digests were unchanged. The bounded process tree reported no OOM events.

These checks expose a distinct remaining capacity problem: the parent rejects the earlier file's completed semantic graph because it reserves 80% of its original result budget whenever any later source remains. Increasing the parent old-space setting to 2,048 MiB still reproduced that admission problem. A reduced inert two-file fixture independently confirms it. That owner-side behavior and its misleading worker-memory recovery guidance are now tracked in #1911.

For the full default-detail MCP response, the existing receive-buffer protection returns a typed transport resource constraint and a retained Evidence reference. The reference is usable through the Evidence bundle, and the session remains healthy. This is separate from semantic-worker exhaustion and is not evidence that retained-result recovery is absent.

Several semantic allocation changes have landed since the originally observed revision, including #1665's self-alias path handling. Their individual causal effects on this input have not been isolated, so I am not attributing the historical failure to a particular commit. Follow-up acceptance will verify the reduced fixture and shared CLI/MCP workflows after the parent-admission fix.

<!-- gh-comment-id:6111650325 --> @N0zoM1z0 commented on GitHub (Oct 11, 2026): Current-main investigation at `898d5096f94fe1ed3ea7d091455e638cc7d23bfd` no longer reproduces the original worker-heap exhaustion on the same two generated wrappers (439,680 and 438,705 bytes). The worker heap setting remained 1,024 MiB. Both CLI analysis and a fresh stdio MCP session completed analysis without that worker failure; MCP remained responsive to a subsequent ping, and artifact digests were unchanged. The bounded process tree reported no OOM events. These checks expose a distinct remaining capacity problem: the parent rejects the earlier file's completed semantic graph because it reserves 80% of its original result budget whenever any later source remains. Increasing the parent old-space setting to 2,048 MiB still reproduced that admission problem. A reduced inert two-file fixture independently confirms it. That owner-side behavior and its misleading worker-memory recovery guidance are now tracked in #1911. For the full default-detail MCP response, the existing receive-buffer protection returns a typed transport resource constraint and a retained Evidence reference. The reference is usable through the Evidence bundle, and the session remains healthy. This is separate from semantic-worker exhaustion and is not evidence that retained-result recovery is absent. Several semantic allocation changes have landed since the originally observed revision, including #1665's self-alias path handling. Their individual causal effects on this input have not been isolated, so I am not attributing the historical failure to a particular commit. Follow-up acceptance will verify the reduced fixture and shared CLI/MCP workflows after the parent-admission fix.
Author
Owner

@N0zoM1z0 commented on GitHub (Oct 11, 2026):

The reported worker-heap exhaustion no longer reproduces on current main. Retested the unchanged 439,680-byte and 438,705-byte released JavaScript sources with the original 1,024-MiB worker heap. Workers now finish semantic analysis. The individual causal effects of preceding upstream changes were not isolated.

A separate parent graph-admission defect was recorded as #1911 and fixed in #1921. The final real CLI run completed in 35.35 seconds under one CPU and a 3-GiB whole-process scope, with a 1,002,668,032-byte peak and zero scope OOM events. Both sources retained 20,000 semantic nodes. Coverage remains explicitly partial under the existing semantic node ceilings.

A fresh stdio MCP run completed in 32.02 seconds; summary delivery, retained module views, canonical Evidence retrieval and session ping passed. No worker-heap or parent-admission failure limits remained, and all target bytes and digests were unchanged. #1921 now has all 31 CI checks passing, including CI required. Historical failed-run evidence is retained without changing its interpretation.

<!-- gh-comment-id:6112314668 --> @N0zoM1z0 commented on GitHub (Oct 11, 2026): The reported worker-heap exhaustion no longer reproduces on current main. Retested the unchanged 439,680-byte and 438,705-byte released JavaScript sources with the original 1,024-MiB worker heap. Workers now finish semantic analysis. The individual causal effects of preceding upstream changes were not isolated. A separate parent graph-admission defect was recorded as #1911 and fixed in #1921. The final real CLI run completed in 35.35 seconds under one CPU and a 3-GiB whole-process scope, with a 1,002,668,032-byte peak and zero scope OOM events. Both sources retained 20,000 semantic nodes. Coverage remains explicitly partial under the existing semantic node ceilings. A fresh stdio MCP run completed in 32.02 seconds; summary delivery, retained module views, canonical Evidence retrieval and session ping passed. No worker-heap or parent-admission failure limits remained, and all target bytes and digests were unchanged. #1921 now has all 31 CI checks passing, including CI required. Historical failed-run evidence is retained without changing its interpretation.
Sign in to join this conversation.
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#622
No description provided.