[GH-ISSUE #3671] [Bug] resource_constraint application_projection_failure reports required bytes far below the budget; per-file Electron findings missing from graph (VSCodium 1.140) #1383

New issue

Open

opened 2026-10-16 21:04:54 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-16 21:04:54 +00:00

Owner

Originally created by @andresaragon on GitHub (Oct 14, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/3671

Summary: in analyze-javascript-application, application_projection_failure reports resource_constraint with figures that contradict the message: the required bytes are orders of magnitude below the reported budget. The affected files lose their Electron findings in the graph.

Version / environment: rea-agents@6.4.0, Node 24.21.0, Linux x64 (WSL2). Input: VSCodium 1.140.06880 linux-x64 (MIT build of VS Code), resources/app without node_modules and extensions (30 JS files, 68 MB). Run with --max-heap-mb 6144 --analysis-timeout-ms 900000; the default heap gives the same result.

Observed (normalized_result.graph.nodes[].observations[].properties.application_projection_failure):

out/vs/workbench/workbench.desktop.main.js       parse_status: failed
  code: resource_constraint
  message: "Expanded application relationships for ... exceed the parent's result budget; complete static facts were retained on the file node"
  reported_limits: { parent_result_budget_bytes: 2070338040, application_projection_required_bytes: 16032 }

out/vs/platform/browserView/electron-browser/preload-browserView.js   parse_status: partial
  code: resource_constraint
  reported_limits: { parent_result_budget_bytes: 2070338040, application_projection_required_bytes: 3336224 }

Required 16,032 B against a 2.07 GB budget, and 3.3 MB against the same budget, are both far below the limit, so "exceeds the budget" does not follow. This looks like the parent budget being consumed or mis-accounted, not a per-file overflow.

Consequence for the small preload: the 49 KB preload-browserView.js contains contextBridge.exposeInMainWorld("__vscode_helpers", ...) and exposeInIsolatedWorld(999, "browserViewAPI", ...). Analyzed alone (a directory with only that file plus a package.json), REA reports both as context-bridge-api nodes. Analyzed inside the full app, both appear only in that file's static_analysis.electron.context_bridge_apis (summary says context_bridge_apis: 4), but the graph has only 2 context-bridge-api nodes (the two vscode ones from preload.js and preload-aux.js). So the same file yields graph nodes or not depending on what else is in the application.

Also in this run preload_entrypoints is 0. The three preloads are referenced from BrowserWindow options through a computed path (FileAccess.asFileUri('vs/base/parts/sandbox/electron-browser/preload.js').fsPath), so the link is not recovered. That part is probably a known limitation of static resolution; I mention it only because electron.preload_entrypoints: 0 reads as "no preloads" while three exist.

Repro:

curl -LO https://github.com/VSCodium/vscodium/releases/download/1.140.06880/VSCodium-linux-x64-1.140.06880.tar.gz
mkdir vscodium && tar -xzf VSCodium-linux-x64-1.140.06880.tar.gz -C vscodium
rsync -a --exclude node_modules --exclude node_modules.asar --exclude node_modules.asar.unpacked --exclude extensions vscodium/resources/app/ app/
npx -y rea-agents@6.4.0 analyze-javascript-application "$PWD/app" --json > out.json
# then compare summary.context_bridge_apis (4) with the count of nodes of kind "context-bridge-api" in graph.nodes (2)

The matching source is microsoft/vscode tag 1.140.0 (same commit date as the build), if useful as ground truth.

Expected: if the budget really is exhausted, say so with consistent numbers; and keep promoting per-file Electron findings to graph nodes independently of other files' failures.

Originally created by @andresaragon on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3671 **Summary:** in `analyze-javascript-application`, `application_projection_failure` reports `resource_constraint` with figures that contradict the message: the required bytes are orders of magnitude below the reported budget. The affected files lose their Electron findings in the graph. **Version / environment:** `rea-agents@6.4.0`, Node 24.21.0, Linux x64 (WSL2). Input: VSCodium 1.140.06880 linux-x64 (MIT build of VS Code), `resources/app` without `node_modules` and `extensions` (30 JS files, 68 MB). Run with `--max-heap-mb 6144 --analysis-timeout-ms 900000`; the default heap gives the same result. **Observed** (`normalized_result.graph.nodes[].observations[].properties.application_projection_failure`): ``` out/vs/workbench/workbench.desktop.main.js parse_status: failed code: resource_constraint message: "Expanded application relationships for ... exceed the parent's result budget; complete static facts were retained on the file node" reported_limits: { parent_result_budget_bytes: 2070338040, application_projection_required_bytes: 16032 } out/vs/platform/browserView/electron-browser/preload-browserView.js parse_status: partial code: resource_constraint reported_limits: { parent_result_budget_bytes: 2070338040, application_projection_required_bytes: 3336224 } ``` Required 16,032 B against a 2.07 GB budget, and 3.3 MB against the same budget, are both far below the limit, so "exceeds the budget" does not follow. This looks like the parent budget being consumed or mis-accounted, not a per-file overflow. **Consequence for the small preload:** the 49 KB `preload-browserView.js` contains `contextBridge.exposeInMainWorld("__vscode_helpers", ...)` and `exposeInIsolatedWorld(999, "browserViewAPI", ...)`. Analyzed **alone** (a directory with only that file plus a `package.json`), REA reports both as `context-bridge-api` nodes. Analyzed inside the full app, both appear only in that file's `static_analysis.electron.context_bridge_apis` (summary says `context_bridge_apis: 4`), but the graph has only 2 `context-bridge-api` nodes (the two `vscode` ones from `preload.js` and `preload-aux.js`). So the same file yields graph nodes or not depending on what else is in the application. Also in this run `preload_entrypoints` is 0. The three preloads are referenced from `BrowserWindow` options through a computed path (`FileAccess.asFileUri('vs/base/parts/sandbox/electron-browser/preload.js').fsPath`), so the link is not recovered. That part is probably a known limitation of static resolution; I mention it only because `electron.preload_entrypoints: 0` reads as "no preloads" while three exist. **Repro:** ```bash curl -LO https://github.com/VSCodium/vscodium/releases/download/1.140.06880/VSCodium-linux-x64-1.140.06880.tar.gz mkdir vscodium && tar -xzf VSCodium-linux-x64-1.140.06880.tar.gz -C vscodium rsync -a --exclude node_modules --exclude node_modules.asar --exclude node_modules.asar.unpacked --exclude extensions vscodium/resources/app/ app/ npx -y rea-agents@6.4.0 analyze-javascript-application "$PWD/app" --json > out.json # then compare summary.context_bridge_apis (4) with the count of nodes of kind "context-bridge-api" in graph.nodes (2) ``` The matching source is `microsoft/vscode` tag `1.140.0` (same commit date as the build), if useful as ground truth. **Expected:** if the budget really is exhausted, say so with consistent numbers; and keep promoting per-file Electron findings to graph nodes independently of other files' failures.

bsakaguchi commented

2026-10-16 21:04:55 +00:00

Author

Owner

@kaoru0822-kitauji commented on GitHub (Oct 15, 2026):

I re-measured this on current main (084e540) against VS Code's resources/app/out (39 relevant files, 63 MB text, default limits, macOS arm64, Node 26.5):

The figures are consistent now. Failures report parent_available_result_budget_bytes next to the total budget, e.g. extensionHostProcess.js: available 9,649,292 B, required 19,281,824 B. Eight files lose their application projection this way.
Graph promotion: summary.context_bridge_apis = 4 and there are 4 context-bridge-api graph nodes in this build, so I could not reproduce the missing preload bridge nodes here (with #3782 the two workbench bundles also parse now).

Why the 2.0 GB budget runs out: the parent charges javaScriptTransferRetentionBytes = bytes × 8 + records × 64 per worker transfer. I decoded real transfers with readJavaScriptAnalysisTransfer and measured the retained heap:

file	source	transfer	estimated	retained after decode
`service-worker.js`	0.04 MB	2.5 MB	20.5 MB	3.3 MB
`localFileSearchMain.js`	0.15 MB	36.9 MB	298 MB	44.1 MB
`extensionHostProcess.js`	2.2 MB	616 MB	4,981 MB	739 MB

For the whole run, a preloaded heap sampler puts the parent's peak heapUsed at 1,070 MB, including graph sealing and output serialization. Meanwhile about 2.0 GB of estimated retention had been charged against the budget, which is half of the free heap.

Transfer amplification is the larger cost: 280–370× the source bytes. Most of it is per-record 64-hex node/relation IDs and repeated evidence locations: for localFileSearchMain.js, node.evidence + node.identity + relation.evidence make up 16.9 MB of the 38.7 MB.

The 8× factor looks deliberately conservative, since it also covers later sealing and serialization copies, so I have not changed it. A per-phase measured factor, or a more compact transfer encoding, would keep these files' projections without risking the parent heap. I'm happy to take either one if a maintainer confirms the direction.

@kaoru0822-kitauji commented on GitHub (Oct 15, 2026): I re-measured this on current `main` (084e540) against VS Code's `resources/app/out` (39 relevant files, 63 MB text, default limits, macOS arm64, Node 26.5): - **The figures are consistent now.** Failures report `parent_available_result_budget_bytes` next to the total budget, e.g. `extensionHostProcess.js`: available 9,649,292 B, required 19,281,824 B. Eight files lose their application projection this way. - **Graph promotion:** `summary.context_bridge_apis` = 4 and there are 4 `context-bridge-api` graph nodes in this build, so I could not reproduce the missing preload bridge nodes here (with #3782 the two workbench bundles also parse now). - **Why the 2.0 GB budget runs out:** the parent charges `javaScriptTransferRetentionBytes = bytes × 8 + records × 64` per worker transfer. I decoded real transfers with `readJavaScriptAnalysisTransfer` and measured the retained heap: | file | source | transfer | estimated | retained after decode | |---|---:|---:|---:|---:| | `service-worker.js` | 0.04 MB | 2.5 MB | 20.5 MB | 3.3 MB | | `localFileSearchMain.js` | 0.15 MB | 36.9 MB | 298 MB | 44.1 MB | | `extensionHostProcess.js` | 2.2 MB | 616 MB | 4,981 MB | 739 MB | For the whole run, a preloaded heap sampler puts the parent's peak `heapUsed` at **1,070 MB**, including graph sealing and output serialization. Meanwhile about 2.0 GB of estimated retention had been charged against the budget, which is half of the free heap. - **Transfer amplification is the larger cost:** 280–370× the source bytes. Most of it is per-record 64-hex node/relation IDs and repeated evidence locations: for `localFileSearchMain.js`, `node.evidence` + `node.identity` + `relation.evidence` make up 16.9 MB of the 38.7 MB. The 8× factor looks deliberately conservative, since it also covers later sealing and serialization copies, so I have not changed it. A per-phase measured factor, or a more compact transfer encoding, would keep these files' projections without risking the parent heap. I'm happy to take either one if a maintainer confirms the direction.

bsakaguchi commented

2026-10-16 21:04:55 +00:00

Author

Owner

@andresaragon commented on GitHub (Oct 15, 2026):

Thanks for re-measuring on main. I checked the published 6.5.0 on the same input (VSCodium 1.140.06880, resources/app without node_modules/extensions, 41 relevant files, default limits, Linux x64, Node 24.21.0):

Bridge promotion: summary.context_bridge_apis = 4 and there are now 4 context-bridge-api graph nodes. On 6.4.0 the graph had only 2. So that part is fixed in 6.5.0; it matches what you see on main.
Workbench bundles: workbench.desktop.main.js (~20 MB) and sessions.desktop.main.js (~21 MB) are still parse_status: "failed" (statistics.parse_failures: 2) on 6.5.0, which is consistent with #3782 landing after the release. You are right that the failure is not only a memory one: the file observation shows parse_error_count: 1 and visited_ast_nodes: 0; I had attributed it to the budget error.
Projection failures: 26 files end as partial on 6.5.0 (6 on 6.4.0); 8 of them carry resource_constraint, which matches your "eight files lose their application projection".

I am not a maintainer, so I can't confirm a direction for the budget estimate. Your measurements of the real retained heap vs. the bytes × 8 + records × 64 charge look like the useful evidence for that decision.

@andresaragon commented on GitHub (Oct 15, 2026): Thanks for re-measuring on `main`. I checked the published **6.5.0** on the same input (VSCodium 1.140.06880, `resources/app` without `node_modules`/`extensions`, 41 relevant files, default limits, Linux x64, Node 24.21.0): - **Bridge promotion:** `summary.context_bridge_apis` = 4 and there are now 4 `context-bridge-api` graph nodes. On 6.4.0 the graph had only 2. So that part is fixed in 6.5.0; it matches what you see on `main`. - **Workbench bundles:** `workbench.desktop.main.js` (~20 MB) and `sessions.desktop.main.js` (~21 MB) are still `parse_status: "failed"` (`statistics.parse_failures: 2`) on 6.5.0, which is consistent with #3782 landing after the release. You are right that the failure is not only a memory one: the file observation shows `parse_error_count: 1` and `visited_ast_nodes: 0`; I had attributed it to the budget error. - **Projection failures:** 26 files end as `partial` on 6.5.0 (6 on 6.4.0); 8 of them carry `resource_constraint`, which matches your "eight files lose their application projection". I am not a maintainer, so I can't confirm a direction for the budget estimate. Your measurements of the real retained heap vs. the `bytes × 8 + records × 64` charge look like the useful evidence for that decision.

bsakaguchi referenced this issue

2026-10-17 21:10:52 +00:00

[PR #1378] [MERGED] fix(apple): scope keyed archive traversal to the selection #2839

bsakaguchi referenced this issue

2026-10-17 21:10:55 +00:00

[PR #1383] [MERGED] chore(release/6.3.0): release rea-agents 6.3.0 #2843