morluto/rea

Fork 0

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

[GH-ISSUE #4601] JavaScript analysis: 6.3.0 stalls on a 277 KB webpack factory and returns exit 0 for Set-limit failures; 6.5.0 still loses the factory's semantic analysis #2387

New issue

Closed

opened 2026-10-17 21:04:02 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-17 21:04:02 +00:00

Owner

Originally created by @shyamsivakumar on GitHub (Oct 16, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4601

Summary and current-release check

Two JavaScript-analysis failures were recorded on rea-agents 6.3.0:

Static analysis stalls on one webpack module factory from public npm package @qodo/command@0.36.0, dist/cli.js. The isolated input is 276,777 bytes, including an export wrapper. A fresh public-tarball reproduction on 2026-10-16 produced no stdout and remained at Parsing and projecting module.js (1/1) until an external 120-second cap killed it.
Large individual browser bundles can produce RangeError: Set maximum size exceeded. The CLI returns an execution_failure JSON envelope but exits 0 in the recorded application runs.

Newer releases exist: npm reports 6.4.0 (published 2026-10-11) and latest 6.5.0 (published 2026-10-14). 6.4.0's release notes describe reassignment-loop fixes and owned JavaScript workers with heap/time limits and retained partial results. 6.5.0's notes describe further JavaScript relationship fixes.

Important distinction: 6.5.0 mitigates the unbounded parent-process stall in this reproduction, but did not successfully analyze the isolated factory's semantics. A fresh 6.5.0 run returned exit 0 and partial Evidence after 16.01 seconds, with this limitation:

module.js: Resource constraint during analyze_javascript_application: Owned JavaScript worker exhausted its heap while analyzing module.js during semantic

Its syntax statistics show 1 parsed JavaScript file, 50,823 visited AST nodes and 0 parse failures; semantic coverage is partial, truncated: true, with 0 retained relations in every reported semantic family. Reported worker heap limit: 1,098,907,648 bytes; worker timeout: 300,000 ms. The outer NODE_OPTIONS=--max-old-space-size=24576 did not replace that reported worker limit. Thus newer failure containment has shipped, but a complete analysis fix for this public input is not established. The original browser-bundle Set-limit cases were not re-run on 6.5.0.

Environment

Recorded and fresh reproduction environment:

rea --version
6.3.0

node --version
v22.23.1

sw_vers
ProductName:     macOS
ProductVersion:  27.0.1
BuildVersion:    26A434

Apple silicon / arm64; original investigation reports 48 GB RAM. Original analysis used NODE_OPTIONS=--max-old-space-size=24576. Source maps were excluded. Inputs were parsed as inert text; the Qodo CLI and its module factory were never executed.

6.5.0 was invoked separately through a version-pinned npm execution; the installed 6.3.0 executable was not upgraded.

Smallest public reproduction: isolated webpack factory

No proprietary source is attached or quoted. These commands reconstruct the input locally from the public npm tarball, without running its lifecycle scripts or target code. tooling/ and the tarball are outside input/ so REA sees only the isolated file.

work=$(mktemp -d)
cd "$work"
npm pack @qodo/command@0.36.0 --ignore-scripts --silent
# Alternative download, instead of npm pack:
# curl -fL https://registry.npmjs.org/@qodo/command/-/command-0.36.0.tgz \
#   -o qodo-command-0.36.0.tgz

tar -xzf qodo-command-0.36.0.tgz package/dist/cli.js
shasum -a 256 qodo-command-0.36.0.tgz package/dist/cli.js

npm install --prefix tooling --ignore-scripts --no-audit --no-fund --no-save \
  @babel/parser@8.0.4 rea-agents@6.3.0

node <<'NODE'
const fs = require('node:fs');
const crypto = require('node:crypto');
const parser = require('./tooling/node_modules/@babel/parser');
const source = fs.readFileSync('package/dist/cli.js', 'utf8');
const ast = parser.parse(source, { sourceType: 'module' });
const table = ast.program.body
  .flatMap(s => s.type === 'VariableDeclaration' ? s.declarations : [])
  .find(d => d.id.type === 'Identifier' && d.id.name === '__webpack_modules__');
if (!table || table.init.type !== 'ObjectExpression') {
  throw new Error('webpack module table not found');
}
const property = table.init.properties.find(p =>
  p.type === 'ObjectProperty' && p.key.type === 'NumericLiteral' &&
  p.key.value === 0x175ed);
if (!property) throw new Error('factory 0x175ed not found');
const output = 'export const webpackModule_0x175ed = ' +
  source.slice(property.value.start, property.value.end) + ';\n';
fs.mkdirSync('input');
fs.writeFileSync('input/module.js', output);
console.log(JSON.stringify({
  bytes: Buffer.byteLength(output),
  sha256: crypto.createHash('sha256').update(output).digest('hex')
}));
NODE

# This command may need an external wall-time cap on 6.3.0.
NODE_OPTIONS=--max-old-space-size=24576 ./tooling/node_modules/.bin/rea \
  analyze-javascript-application "$work/input" \
  --artifact-format directory --format json > result.json 2> progress.log
status=$?
printf 'exit=%s\n' "$status"

# Compare the same input with the current published version:
NODE_OPTIONS=--max-old-space-size=24576 npm exec --yes --ignore-scripts \
  --package=rea-agents@6.5.0 -- rea analyze-javascript-application "$work/input" \
  --artifact-format directory --format json > result-6.5.0.json 2> progress-6.5.0.log

Expected identity checks, freshly confirmed from the public download:

Tarball SHA-256:
07230b3e5577edcf410961f3014dd9c9f068279bd8edc6eb37462b51dc467d2e
package/dist/cli.js SHA-256:
30a4e644d2433ece1d31a0c4a652fe4af2cf7e52592e2875912fdb8d45367d04
input/module.js: 276777 bytes
input/module.js SHA-256:
b08aae1f5ca81a4e3307e16b982453c43fac8547f23506ed5123496352cb570c

The factory expression itself is 276,738 bytes; the 276,777-byte figure includes the export wrapper and newline.

Fresh observed output, 2026-10-16

The extraction used the installed REA package's @babel/parser 8.0.4; the commands above install the same parser version into an isolated tooling directory. No target source was printed.

6.3.0 command actually run:

NODE_OPTIONS=--max-old-space-size=24576 rea analyze-javascript-application \
  <temporary-workspace>/input --artifact-format directory --format json

An external supervisor capped this at 120 seconds and sent SIGKILL to the owned process group. Elapsed 120.15 seconds; process return code -9 in the supervisor, not a natural CLI exit status; stdout 0 bytes. Last stderr progress:

{"rea_progress":{"phase":"parse_javascript_source","completed":0,"total":1,"message":"Parsing and projecting module.js (1/1)","sequence":4}}

6.5.0 command actually run:

NODE_OPTIONS=--max-old-space-size=24576 npm exec --yes --ignore-scripts \
  --package=rea-agents@6.5.0 -- rea analyze-javascript-application \
  <temporary-workspace>/input --artifact-format directory --format json

Elapsed 16.01 seconds including npm startup/download; exit 0; stdout 32,358 bytes, valid Evidence JSON. Final progress says Application graph and Electron boundaries reconstructed, but the Evidence explicitly reports the semantic worker heap exhaustion described above. This is not a complete semantic-analysis success. These are single diagnostic observations, not benchmark results. Both runs and public-input reconstruction completed within ten minutes. No other original target was re-run.

Problem 1: recorded stall localization

The original dist/cli.js is 34,947,271 bytes. A whole-package run stopped at Parsing and projecting package/dist/cli.js (59/805) for approximately 11 hours before the investigator stopped it. The complete file alone also stalled.

The note records a decomposition of the webpack module table:

All 11 other top-level pieces completed, including the 6.9 MB string-array function.
1,462 of 1,463 factory inputs completed.
Factory 0x175ed was the remaining unresolved input; the stuck 47-factory batch had also remained busy for about 24 minutes.

Those historical decomposition results are reported by the investigation note; its large generated outputs were removed before this report. The fresh hash-matched single-factory run independently establishes noncompletion within 120 seconds, not an infinite loop or a specific complexity bound.

Retained stack samples, restricted to analyzer-side frames

The saved macOS samples do not contain symbolicated REA JavaScript function names or source locations. With Node/V8/OS frames omitted, the relevant whole-file sample contains only this unresolved chain:

7685 ??? (in <unknown binary>) [0x10e0084bc]
7685 ??? (in <unknown binary>) [0x10e028c60]
7685 ??? (in <unknown binary>) [0x10e0b3030]

The stuck factory-batch sample similarly contains:

6943 ??? (in <unknown binary>) [0x10cbb5074]
6943 ??? (in <unknown binary>) [0x10cb9ad38]
6943 ??? (in <unknown binary>) [0x10caea448]
6943 ??? (in <unknown binary>) [0x10caf93b4]

[INFERENCE] These are analyzer-side JIT frames because REA was performing static analysis and did not execute the target. The samples themselves do not identify them as particular REA functions; no named REA-only stack can honestly be supplied from this evidence. There is also no retained JavaScript exception stack for the Set-limit envelope.

For context only, the native samples show active allocation/GC and Set lookup work for the factory batch, and WeakMap rehashing for the whole file. That supports resource-heavy active computation rather than a thread sleeping on a lock. It does not prove an ever-growing worklist, the owning Set/WeakMap, a shared root cause, or mathematical nontermination. No target-owned stack/source is included here.

Problem 2: Set maximum size exceeded, with CLI exit 0

The retained single-file CodeRabbit result contains this diagnostic, with local paths removed:

{
  "error": "JavaScript application analysis failed",
  "code": "execution_failure",
  "category": "execution_failure",
  "retryable": false,
  "details": {
    "provider_id": "rea-javascript-application",
    "operation": "analyze_javascript_application",
    "diagnostics": {
      "error_name": "RangeError",
      "error_message": "Set maximum size exceeded"
    }
  }
}

The note and retained coverage/timing records identify these 6.3.0 failures:

Package/artifact	Last file being projected	Recorded wall time	Recorded peak footprint
CodeRabbit 0.23.0	`webview/build/assets/index.js` (4/5)	1,035.92 s	9.31 GB
Momentic 3.66.0	`run-viewer-static/assets/index-CuIYb3sK.js` (5/13)	9,373.38 s	10.65 GB
`@qodo/command@0.36.0`, excluding `dist/cli.js`	`dist/webapp/dist/assets/index-DK_3kaHQ.js` (612/804)	557.54 s	13.54 GB

The retained timeline records exit=0 for each of those application runs despite the analysis failure. The CodeRabbit browser bundle alone, with package metadata, also produced the retained Set-limit envelope: 1,139.08 seconds and 9,651,833,912-byte peak memory footprint. Its individual exit code is stated in the note's general failure description, but the single-file timeline does not independently record an exit value.

This establishes that the failure need not depend on accumulated analysis across hundreds of files. It does not establish which internal Set grows, whether the three packages share a cause, or that every timed-out Momentic single-file run would eventually throw this exception. In particular, the Momentic single-file 60-minute timeouts are noncompletion observations, not observed Set-limit throws.

A second public-tarball candidate for reproducing the browser failure is available in the same Qodo tarball:

mkdir browser-input
tar -xzf qodo-command-0.36.0.tgz \
  -C browser-input --strip-components=5 \
  package/dist/webapp/dist/assets/index-DK_3kaHQ.js
NODE_OPTIONS=--max-old-space-size=24576 ./tooling/node_modules/.bin/rea \
  analyze-javascript-application "$work/browser-input" \
  --artifact-format directory --format json > browser-result.json 2> browser-progress.log
status=$?
printf 'exit=%s\n' "$status"

Not re-run: this browser-file-only recipe is a candidate based on the recorded failing filename, not a fresh verified minimal Set-error reproduction. The smallest freshly reconstructed and tested public reproduction in this report is the factory input for problem 1. CodeRabbit and Momentic source/assets are not attached or quoted.

Expected versus actual

Expected: static semantic analysis of the isolated factory should finish with useful facts or a precise, bounded explanation of the unsupported construct. Actual: 6.3.0 emits no result within the bounded fresh run; 6.5.0 returns partial Evidence but exhausts its worker heap and retains no semantic relations for this file.
Expected: an analysis-level execution_failure should produce a nonzero CLI exit status. Actual on the recorded 6.3.0 application failures: the JSON reports failure while the process exits 0. This is distinct from a deliberately returned partial Evidence result on 6.5.0; I am not claiming that every partial result should be a process error.
Expected: completed analysis facts should remain accessible after a later-file failure. Historical 6.3.0 actual: the recorded output was a failure envelope, rather than the earlier files' analysis. Shipped mitigation: newer releases explicitly preserve partial facts; that feature is acknowledged rather than requested again here.

Duplicate search and relationship to existing fixes

Checked open and closed issues on 2026-10-16 using:

gh issue list -R morluto/rea --state all --limit 100
gh search issues -R morluto/rea RangeError --limit 100
gh search issues -R morluto/rea stall --limit 100
gh search issues -R morluto/rea '"Set maximum size"' --limit 100
npm view rea-agents version time --json

No exact Set maximum size issue was returned. The last 100 issues contained no matching JavaScript report; a broader text match on stall also found unrelated Ghidra/draw.io issues. The full-history individual searches found related reports, so this is not a claim that REA has no known large-bundle performance bugs:

#1401, closed: reassignment/member-propagation growth. Related fixes shipped in 6.4.0. The current public factory still hits worker heap exhaustion; the unsymbolicated historical samples do not establish that it is the same loop shape.
#1387, closed: a different 6.3.0 production-bundle abort, confirmed fixed on 6.4.0 by its reporter. Its exit-134 heap abort is not the retained Set maximum size exceeded plus exit-0 envelope here.
#3839, open: getter-result combinatorial expansion in another shipped bundle. This may be related, but no shared root cause is demonstrated. This report contributes a public, hash-identified input rather than attaching proprietary code.
#1380, closed: inline source-map size failure; source maps were excluded from this investigation.
#1538, closed: argument-expansion limit, a different exception from the Set-capacity diagnostic.

The 6.4.0/6.5.0 notes establish shipped improvements and failure containment, not a successful complete semantic analysis of this input. Please link/merge this report into an existing issue if the public factory exercises an already-tracked cause.

Originally created by @shyamsivakumar on GitHub (Oct 16, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4601 ## Summary and current-release check Two JavaScript-analysis failures were recorded on `rea-agents` **6.3.0**: 1. Static analysis stalls on one webpack module factory from public npm package `@qodo/command@0.36.0`, `dist/cli.js`. The isolated input is **276,777 bytes**, including an export wrapper. A fresh public-tarball reproduction on 2026-10-16 produced no stdout and remained at `Parsing and projecting module.js (1/1)` until an external 120-second cap killed it. 2. Large individual browser bundles can produce `RangeError: Set maximum size exceeded`. The CLI returns an `execution_failure` JSON envelope but exits **0** in the recorded application runs. **Newer releases exist:** npm reports 6.4.0 (published 2026-10-11) and latest 6.5.0 (published 2026-10-14). [6.4.0's release notes](https://github.com/morluto/rea/releases/tag/rea-agents-6.4.0) describe reassignment-loop fixes and owned JavaScript workers with heap/time limits and retained partial results. [6.5.0's notes](https://github.com/morluto/rea/releases/tag/rea-agents-6.5.0) describe further JavaScript relationship fixes. **Important distinction:** 6.5.0 mitigates the unbounded parent-process stall in this reproduction, but did not successfully analyze the isolated factory's semantics. A fresh 6.5.0 run returned exit 0 and partial Evidence after 16.01 seconds, with this limitation: ```text module.js: Resource constraint during analyze_javascript_application: Owned JavaScript worker exhausted its heap while analyzing module.js during semantic ``` Its syntax statistics show 1 parsed JavaScript file, 50,823 visited AST nodes and 0 parse failures; semantic coverage is `partial`, `truncated: true`, with 0 retained relations in every reported semantic family. Reported worker heap limit: 1,098,907,648 bytes; worker timeout: 300,000 ms. The outer `NODE_OPTIONS=--max-old-space-size=24576` did not replace that reported worker limit. Thus newer failure containment has shipped, but a complete analysis fix for this public input is **not established**. The original browser-bundle Set-limit cases were not re-run on 6.5.0. ## Environment Recorded and fresh reproduction environment: ```text rea --version 6.3.0 node --version v22.23.1 sw_vers ProductName: macOS ProductVersion: 27.0.1 BuildVersion: 26A434 ``` Apple silicon / arm64; original investigation reports 48 GB RAM. Original analysis used `NODE_OPTIONS=--max-old-space-size=24576`. Source maps were excluded. Inputs were parsed as inert text; the Qodo CLI and its module factory were never executed. 6.5.0 was invoked separately through a version-pinned npm execution; the installed 6.3.0 executable was not upgraded. ## Smallest public reproduction: isolated webpack factory No proprietary source is attached or quoted. These commands reconstruct the input locally from the **public npm tarball**, without running its lifecycle scripts or target code. `tooling/` and the tarball are outside `input/` so REA sees only the isolated file. ```sh work=$(mktemp -d) cd "$work" npm pack @qodo/command@0.36.0 --ignore-scripts --silent # Alternative download, instead of npm pack: # curl -fL https://registry.npmjs.org/@qodo/command/-/command-0.36.0.tgz \ # -o qodo-command-0.36.0.tgz tar -xzf qodo-command-0.36.0.tgz package/dist/cli.js shasum -a 256 qodo-command-0.36.0.tgz package/dist/cli.js npm install --prefix tooling --ignore-scripts --no-audit --no-fund --no-save \ @babel/parser@8.0.4 rea-agents@6.3.0 node <<'NODE' const fs = require('node:fs'); const crypto = require('node:crypto'); const parser = require('./tooling/node_modules/@babel/parser'); const source = fs.readFileSync('package/dist/cli.js', 'utf8'); const ast = parser.parse(source, { sourceType: 'module' }); const table = ast.program.body .flatMap(s => s.type === 'VariableDeclaration' ? s.declarations : []) .find(d => d.id.type === 'Identifier' && d.id.name === '__webpack_modules__'); if (!table || table.init.type !== 'ObjectExpression') { throw new Error('webpack module table not found'); } const property = table.init.properties.find(p => p.type === 'ObjectProperty' && p.key.type === 'NumericLiteral' && p.key.value === 0x175ed); if (!property) throw new Error('factory 0x175ed not found'); const output = 'export const webpackModule_0x175ed = ' + source.slice(property.value.start, property.value.end) + ';\n'; fs.mkdirSync('input'); fs.writeFileSync('input/module.js', output); console.log(JSON.stringify({ bytes: Buffer.byteLength(output), sha256: crypto.createHash('sha256').update(output).digest('hex') })); NODE # This command may need an external wall-time cap on 6.3.0. NODE_OPTIONS=--max-old-space-size=24576 ./tooling/node_modules/.bin/rea \ analyze-javascript-application "$work/input" \ --artifact-format directory --format json > result.json 2> progress.log status=$? printf 'exit=%s\n' "$status" # Compare the same input with the current published version: NODE_OPTIONS=--max-old-space-size=24576 npm exec --yes --ignore-scripts \ --package=rea-agents@6.5.0 -- rea analyze-javascript-application "$work/input" \ --artifact-format directory --format json > result-6.5.0.json 2> progress-6.5.0.log ``` Expected identity checks, freshly confirmed from the public download: ```text Tarball SHA-256: 07230b3e5577edcf410961f3014dd9c9f068279bd8edc6eb37462b51dc467d2e package/dist/cli.js SHA-256: 30a4e644d2433ece1d31a0c4a652fe4af2cf7e52592e2875912fdb8d45367d04 input/module.js: 276777 bytes input/module.js SHA-256: b08aae1f5ca81a4e3307e16b982453c43fac8547f23506ed5123496352cb570c ``` The factory expression itself is 276,738 bytes; the 276,777-byte figure includes the export wrapper and newline. ### Fresh observed output, 2026-10-16 The extraction used the installed REA package's `@babel/parser` 8.0.4; the commands above install the same parser version into an isolated tooling directory. No target source was printed. **6.3.0 command actually run:** ```sh NODE_OPTIONS=--max-old-space-size=24576 rea analyze-javascript-application \ <temporary-workspace>/input --artifact-format directory --format json ``` An external supervisor capped this at 120 seconds and sent SIGKILL to the owned process group. Elapsed 120.15 seconds; process return code `-9` in the supervisor, **not** a natural CLI exit status; stdout **0 bytes**. Last stderr progress: ```json {"rea_progress":{"phase":"parse_javascript_source","completed":0,"total":1,"message":"Parsing and projecting module.js (1/1)","sequence":4}} ``` **6.5.0 command actually run:** ```sh NODE_OPTIONS=--max-old-space-size=24576 npm exec --yes --ignore-scripts \ --package=rea-agents@6.5.0 -- rea analyze-javascript-application \ <temporary-workspace>/input --artifact-format directory --format json ``` Elapsed **16.01 seconds including npm startup/download**; exit **0**; stdout **32,358 bytes**, valid Evidence JSON. Final progress says `Application graph and Electron boundaries reconstructed`, but the Evidence explicitly reports the semantic worker heap exhaustion described above. This is not a complete semantic-analysis success. These are single diagnostic observations, not benchmark results. Both runs and public-input reconstruction completed within ten minutes. No other original target was re-run. ## Problem 1: recorded stall localization The original `dist/cli.js` is 34,947,271 bytes. A whole-package run stopped at `Parsing and projecting package/dist/cli.js (59/805)` for approximately 11 hours before the investigator stopped it. The complete file alone also stalled. The note records a decomposition of the webpack module table: - All 11 other top-level pieces completed, including the 6.9 MB string-array function. - 1,462 of 1,463 factory inputs completed. - Factory `0x175ed` was the remaining unresolved input; the stuck 47-factory batch had also remained busy for about 24 minutes. Those historical decomposition results are **reported by the investigation note**; its large generated outputs were removed before this report. The fresh hash-matched single-factory run independently establishes noncompletion within 120 seconds, not an infinite loop or a specific complexity bound. ### Retained stack samples, restricted to analyzer-side frames The saved macOS samples do **not** contain symbolicated REA JavaScript function names or source locations. With Node/V8/OS frames omitted, the relevant whole-file sample contains only this unresolved chain: ```text 7685 ??? (in <unknown binary>) [0x10e0084bc] 7685 ??? (in <unknown binary>) [0x10e028c60] 7685 ??? (in <unknown binary>) [0x10e0b3030] ``` The stuck factory-batch sample similarly contains: ```text 6943 ??? (in <unknown binary>) [0x10cbb5074] 6943 ??? (in <unknown binary>) [0x10cb9ad38] 6943 ??? (in <unknown binary>) [0x10caea448] 6943 ??? (in <unknown binary>) [0x10caf93b4] ``` **[INFERENCE]** These are analyzer-side JIT frames because REA was performing static analysis and did not execute the target. The samples themselves do not identify them as particular REA functions; no named REA-only stack can honestly be supplied from this evidence. There is also no retained JavaScript exception stack for the Set-limit envelope. For context only, the native samples show active allocation/GC and Set lookup work for the factory batch, and WeakMap rehashing for the whole file. That supports resource-heavy active computation rather than a thread sleeping on a lock. It does **not** prove an ever-growing worklist, the owning Set/WeakMap, a shared root cause, or mathematical nontermination. No target-owned stack/source is included here. ## Problem 2: Set maximum size exceeded, with CLI exit 0 The retained single-file CodeRabbit result contains this diagnostic, with local paths removed: ```json { "error": "JavaScript application analysis failed", "code": "execution_failure", "category": "execution_failure", "retryable": false, "details": { "provider_id": "rea-javascript-application", "operation": "analyze_javascript_application", "diagnostics": { "error_name": "RangeError", "error_message": "Set maximum size exceeded" } } } ``` The note and retained coverage/timing records identify these 6.3.0 failures: | Package/artifact | Last file being projected | Recorded wall time | Recorded peak footprint | | --- | --- | ---: | ---: | | CodeRabbit 0.23.0 | `webview/build/assets/index.js` (4/5) | 1,035.92 s | 9.31 GB | | Momentic 3.66.0 | `run-viewer-static/assets/index-CuIYb3sK.js` (5/13) | 9,373.38 s | 10.65 GB | | `@qodo/command@0.36.0`, excluding `dist/cli.js` | `dist/webapp/dist/assets/index-DK_3kaHQ.js` (612/804) | 557.54 s | 13.54 GB | The retained timeline records **exit=0** for each of those application runs despite the analysis failure. The CodeRabbit browser bundle alone, with package metadata, also produced the retained Set-limit envelope: 1,139.08 seconds and 9,651,833,912-byte peak memory footprint. Its individual exit code is stated in the note's general failure description, but the single-file timeline does not independently record an exit value. This establishes that the failure need not depend on accumulated analysis across hundreds of files. It does **not** establish which internal Set grows, whether the three packages share a cause, or that every timed-out Momentic single-file run would eventually throw this exception. In particular, the Momentic single-file 60-minute timeouts are noncompletion observations, not observed Set-limit throws. A second public-tarball candidate for reproducing the browser failure is available in the same Qodo tarball: ```sh mkdir browser-input tar -xzf qodo-command-0.36.0.tgz \ -C browser-input --strip-components=5 \ package/dist/webapp/dist/assets/index-DK_3kaHQ.js NODE_OPTIONS=--max-old-space-size=24576 ./tooling/node_modules/.bin/rea \ analyze-javascript-application "$work/browser-input" \ --artifact-format directory --format json > browser-result.json 2> browser-progress.log status=$? printf 'exit=%s\n' "$status" ``` **Not re-run:** this browser-file-only recipe is a candidate based on the recorded failing filename, not a fresh verified minimal Set-error reproduction. The smallest freshly reconstructed and tested public reproduction in this report is the factory input for problem 1. CodeRabbit and Momentic source/assets are not attached or quoted. ## Expected versus actual - **Expected:** static semantic analysis of the isolated factory should finish with useful facts or a precise, bounded explanation of the unsupported construct. **Actual:** 6.3.0 emits no result within the bounded fresh run; 6.5.0 returns partial Evidence but exhausts its worker heap and retains no semantic relations for this file. - **Expected:** an analysis-level `execution_failure` should produce a nonzero CLI exit status. **Actual on the recorded 6.3.0 application failures:** the JSON reports failure while the process exits 0. This is distinct from a deliberately returned partial Evidence result on 6.5.0; I am not claiming that every partial result should be a process error. - **Expected:** completed analysis facts should remain accessible after a later-file failure. **Historical 6.3.0 actual:** the recorded output was a failure envelope, rather than the earlier files' analysis. **Shipped mitigation:** newer releases explicitly preserve partial facts; that feature is acknowledged rather than requested again here. ## Duplicate search and relationship to existing fixes Checked open and closed issues on 2026-10-16 using: ```sh gh issue list -R morluto/rea --state all --limit 100 gh search issues -R morluto/rea RangeError --limit 100 gh search issues -R morluto/rea stall --limit 100 gh search issues -R morluto/rea '"Set maximum size"' --limit 100 npm view rea-agents version time --json ``` No exact `Set maximum size` issue was returned. The last 100 issues contained no matching JavaScript report; a broader text match on `stall` also found unrelated Ghidra/draw.io issues. The full-history individual searches found related reports, so this is **not** a claim that REA has no known large-bundle performance bugs: - [#1401](https://github.com/morluto/rea/issues/1401), closed: reassignment/member-propagation growth. Related fixes shipped in 6.4.0. The current public factory still hits worker heap exhaustion; the unsymbolicated historical samples do not establish that it is the same loop shape. - [#1387](https://github.com/morluto/rea/issues/1387), closed: a different 6.3.0 production-bundle abort, confirmed fixed on 6.4.0 by its reporter. Its exit-134 heap abort is not the retained `Set maximum size exceeded` plus exit-0 envelope here. - [#3839](https://github.com/morluto/rea/issues/3839), open: getter-result combinatorial expansion in another shipped bundle. This may be related, but no shared root cause is demonstrated. This report contributes a public, hash-identified input rather than attaching proprietary code. - [#1380](https://github.com/morluto/rea/issues/1380), closed: inline source-map size failure; source maps were excluded from this investigation. - [#1538](https://github.com/morluto/rea/issues/1538), closed: argument-expansion limit, a different exception from the Set-capacity diagnostic. The 6.4.0/6.5.0 notes establish shipped improvements and failure containment, not a successful complete semantic analysis of this input. Please link/merge this report into an existing issue if the public factory exercises an already-tracked cause.

bsakaguchi commented

2026-10-17 21:04:02 +00:00

Author

Owner

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

Independent current-main reproduction at d74e72406: the public tarball, full CLI file and extracted 276777-byte factory match all three reported SHA-256 identities. Public CLI analysis on pinned Node24.18.0 returned partial Evidence in one diagnostic run (8.32s), reporting semantic worker heap exhaustion with zero retained semantic relations. No package scripts or target code executed. The AST has50823 nodes and zero getters/classes, so #3839's getter issue is separate for this input.

Per the maintainer's request, Flameox CPU/allocation profiling now covers the actual semantic analyzer from a clean d74e72406 checkout. Two separate2.5-second windows were deliberately stopped before OOM:

Returned-reference resolver:924/2057 CPU self hits (44.9%). completeExpansion:92/2057 (4.5%). markValue:117/2057 (5.7%). GC:162/2057 (7.9%).
V8 sampling including collected objects estimates4.59GB allocation volume in its window. Resolver self allocation1.84GB (40.1%), completeExpansion261.9MB (5.7%). This is estimated allocation traffic, not retained heap or peak RSS.

Source-derived next experiment: returned-reference resolution copies initializer-history Sets and retains blocker-context antichains per AST node/path. Runtime costs point here, but do not yet prove a causal fix. Separate mutation instrumentation observed one write queue reach168391 entries with retained histories of38-40 entries before a256MiB diagnostic heap failure. Attempts to share depth tries and release consumed queue entries still lost semantic facts; those source edits were discarded and no improvement is claimed.

The first full Flameox capture OOMed before Node flushed a CPU artifact. A bounded inspector window produced native profiles, which Flameox validated/ranked and preserved. CPU SHA-256:4a93ef6b30ebf1aa87d7abfd29015f1fe2a5ad47ebb4dd36c900f8b2cda27bb4. Heap profile SHA-256:7522ab6d29d70e8b15e9fcefe2273c2b62a3a9098f5e2c06117027fd284e4a1a. Capture/store limitations are retained locally: idle parent excluded, default-store format unsupported, allocation capture exceeded its writable-output bound but its full local native artifact was separately validated and preserved without recapture.

These are diagnostic windows, not whole-task benchmarks, a completed semantic analysis, or a fixed bug. Historical6.3 Set-capacity/exit-status cases remain unverified. Investigation continues.

@morluto commented on GitHub (Oct 16, 2026): Independent current-main reproduction at d74e72406: the public tarball, full CLI file and extracted 276777-byte factory match all three reported SHA-256 identities. Public CLI analysis on pinned Node24.18.0 returned partial Evidence in one diagnostic run (8.32s), reporting semantic worker heap exhaustion with zero retained semantic relations. No package scripts or target code executed. The AST has50823 nodes and zero getters/classes, so #3839's getter issue is separate for this input. Per the maintainer's request, Flameox CPU/allocation profiling now covers the actual semantic analyzer from a clean d74e72406 checkout. Two separate2.5-second windows were deliberately stopped before OOM: - Returned-reference resolver:924/2057 CPU self hits (44.9%). `completeExpansion`:92/2057 (4.5%). `markValue`:117/2057 (5.7%). GC:162/2057 (7.9%). - V8 sampling including collected objects estimates4.59GB allocation volume in its window. Resolver self allocation1.84GB (40.1%), `completeExpansion`261.9MB (5.7%). This is estimated allocation traffic, **not retained heap or peak RSS**. Source-derived next experiment: returned-reference resolution copies initializer-history Sets and retains blocker-context antichains per AST node/path. Runtime costs point here, but do not yet prove a causal fix. Separate mutation instrumentation observed one write queue reach168391 entries with retained histories of38-40 entries before a256MiB diagnostic heap failure. Attempts to share depth tries and release consumed queue entries still lost semantic facts; those source edits were discarded and no improvement is claimed. The first full Flameox capture OOMed before Node flushed a CPU artifact. A bounded inspector window produced native profiles, which Flameox validated/ranked and preserved. CPU SHA-256:4a93ef6b30ebf1aa87d7abfd29015f1fe2a5ad47ebb4dd36c900f8b2cda27bb4. Heap profile SHA-256:7522ab6d29d70e8b15e9fcefe2273c2b62a3a9098f5e2c06117027fd284e4a1a. Capture/store limitations are retained locally: idle parent excluded, default-store format unsupported, allocation capture exceeded its writable-output bound but its full local native artifact was separately validated and preserved without recapture. These are diagnostic windows, not whole-task benchmarks, a completed semantic analysis, or a fixed bug. Historical6.3 Set-capacity/exit-status cases remain unverified. Investigation continues.

bsakaguchi closed this issue

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

bsakaguchi commented

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

Author

Owner

@SII-YDD commented on GitHub (Oct 25, 2026):

AI-assisted reproduction on the unmodified main snapshot bb17e90f27dc8908c1c91c05055679678768c266 (2026-10-25). The public tarball, original cli.js, and extracted 276,777-byte factory match all three SHA-256 values in this report; npm archive integrity was also verified. No Qodo target code or Qodo package scripts were executed.

Public CLI: node scripts/rea.mjs analyze-javascript-application /fixtures/4601 --artifact-format directory --format json --max-heap-mb 1024 --analysis-timeout-ms <budget>.

Source budget	Payload outcome	Wall seconds	Family CPU seconds	Kernel family peak MiB
60,000 ms	`provider_timeout`, exit 1	60.949	68.842	896.9
300,000 ms (default)	`provider_timeout`, exit 1	301.011	330.268	1153.4

Both retain partial Evidence with the source digest, zero completed parsed files and zero semantic relations. There were no observed OOM events; owned work settled. These finite timeouts do not establish an infinite loop.

A separate 15-second in-process diagnostic, deliberately stopped after saving its CPU profile, finished parsing and binding collection, then ambient indexing (~2.39 s), and remained in member-mutation indexing. Of 7,275 samples, the self shares were position 19.67%, statementPosition 8.82%, and semanticEffectTiming 8.12%. This is not a completed-task benchmark or proof of a causal optimization. Open #2041 already proposes changes to this timing/ancestry owner, so I did not write a competing cache patch or test that PR's implementation.

Real stdio MCP, with actual advertised output schemas and the shared verifier helpers, also returned the 60-second timeout; on that same connection, ping, retained-partial summary readback, a successful small-source analysis, and another ping passed. The retained Evidence ID matches the CLI's 60-second partial. Inputs remained unchanged; the client/server and private temporary resources were released.

Host: Linux arm64, pinned Node 24.22.1/npm 11.16.0, fresh offline container per CLI case, 2 CPUs, 6 GiB hard family limit/no swap, 3.5 GiB early stop, CLI parent heap 3 GiB. CPU includes container helpers; peak includes file cache. OS caches were not flushed and other host load was unmeasured. No completed large-file IR equivalence, accuracy, token reduction, or before/after performance improvement is established.

@SII-YDD commented on GitHub (Oct 25, 2026): AI-assisted reproduction on the unmodified `main` snapshot `bb17e90f27dc8908c1c91c05055679678768c266` (2026-10-25). The public tarball, original `cli.js`, and extracted 276,777-byte factory match all three SHA-256 values in this report; npm archive integrity was also verified. No Qodo target code or Qodo package scripts were executed. Public CLI: `node scripts/rea.mjs analyze-javascript-application /fixtures/4601 --artifact-format directory --format json --max-heap-mb 1024 --analysis-timeout-ms <budget>`. | Source budget | Payload outcome | Wall seconds | Family CPU seconds | Kernel family peak MiB | | --- | --- | ---: | ---: | ---: | | 60,000 ms | `provider_timeout`, exit 1 | 60.949 | 68.842 | 896.9 | | 300,000 ms (default) | `provider_timeout`, exit 1 | 301.011 | 330.268 | 1153.4 | Both retain partial Evidence with the source digest, zero completed parsed files and zero semantic relations. There were no observed OOM events; owned work settled. These finite timeouts do not establish an infinite loop. A separate 15-second **in-process diagnostic**, deliberately stopped after saving its CPU profile, finished parsing and binding collection, then ambient indexing (~2.39 s), and remained in member-mutation indexing. Of 7,275 samples, the self shares were `position` 19.67%, `statementPosition` 8.82%, and `semanticEffectTiming` 8.12%. This is not a completed-task benchmark or proof of a causal optimization. Open #2041 already proposes changes to this timing/ancestry owner, so I did not write a competing cache patch or test that PR's implementation. Real stdio MCP, with actual advertised output schemas and the shared verifier helpers, also returned the 60-second timeout; on that same connection, ping, retained-partial summary readback, a successful small-source analysis, and another ping passed. The retained Evidence ID matches the CLI's 60-second partial. Inputs remained unchanged; the client/server and private temporary resources were released. Host: Linux arm64, pinned Node 24.22.1/npm 11.16.0, fresh offline container per CLI case, 2 CPUs, 6 GiB hard family limit/no swap, 3.5 GiB early stop, CLI parent heap 3 GiB. CPU includes container helpers; peak includes file cache. OS caches were not flushed and other host load was unmeasured. No completed large-file IR equivalence, accuracy, token reduction, or before/after performance improvement is established.

bsakaguchi referenced this issue

2026-10-31 01:04:44 +00:00

[PR #2387] [MERGED] fix(scripts): pass MCP callTool timeouts as request options #5197

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

No description provided.

Rows
Columns