[GH-ISSUE #7170] analyze-javascript-application: semantic phase never completes on a 6.5 MB minified Electron main.js (3 timeouts, incl. reduced semantic limits) #4293

New issue

Open

opened 2026-10-31 00:48:35 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-31 00:48:35 +00:00

Owner

Originally created by @juanfrilopez on GitHub (Oct 25, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/7170

Summary

analyze-javascript-application never completes the semantic phase for a single large minified file (dist/main.js, 6.5 MB, webpack bundle of an Electron main process). The static phase completes in minutes; the semantic phase runs until the per-source deadline in every attempt. Smaller files in the same artifact analyze fine.

Environment

rea-agents 6.8.0 (npm global)
Node.js 26.12.1 (also reproduced on 24.10.0 before upgrading)
macOS (Apple Silicon, Homebrew), 32 GB-class host
Target: app.asar of a real Electron app (Canva Desktop 1.126.2); the failing source is dist/main.js inside the asar

Steps to reproduce

rea analyze-javascript-application /Applications/Canva.app/Contents/Resources/app.asar \
  --format json --source-path dist/main.js \
  --analysis-timeout-ms 3600000 --max-heap-mb 2048 \
  --max-semantic-nodes 2000 --max-semantic-nodes-per-file 2000 \
  --max-semantic-unknowns 1000 --max-semantic-unknowns-per-file 1000

Attempts

#	analysis-timeout-ms	semantic limits	result
1	300000	defaults	timeout in `javascript_worker_semantic` (152-file run; other 151 files fine)
2	3600000	defaults	timeout in `javascript_worker_semantic`
3	3600000	nodes 2000/file 2000/unknowns 1000	timeout in `javascript_worker_semantic`

Progress output always reaches javascript_worker_static: dist/main.js and then stalls at javascript_worker_semantic: dist/main.js until the deadline.

Expected

Either completion, or bounded early exit with partial semantic projection when limits are lowered (attempt 3 sets very low node/unknown caps, yet runtime is unchanged, which suggests unbounded work before projection rather than retention overflow).

Actual

{"code":"provider_timeout","category":"timeout","message":"JavaScript source analysis reached its 3600000ms per-source server/provider deadline (analysis_timeout_ms), not the MCP client deadline.","retryable":true}

Notes

File size/shape: 6.5 MB, heavily minified, single webpack runtime + bundled modules, no source map
Memory does not appear to be the constraint (--max-heap-mb 2048, no OOM); the run is CPU-bound in the semantic worker
Possibly relevant: the bundle contains very large single expressions and deeply nested call chains typical of minified output; if the semantic pass has super-linear behavior on expression depth/size, this input may trigger it
Happy to provide the exact artifact privately if useful; it is a public app bundle (asar of a widely distributed Electron app)

Thanks! The static + semantic analysis of the other 151 sources of the same artifact worked beautifully.

Originally created by @juanfrilopez on GitHub (Oct 25, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7170 ## Summary `analyze-javascript-application` never completes the semantic phase for a single large minified file (`dist/main.js`, 6.5 MB, webpack bundle of an Electron main process). The static phase completes in minutes; the semantic phase runs until the per-source deadline in every attempt. Smaller files in the same artifact analyze fine. ## Environment - `rea-agents` 6.8.0 (npm global) - Node.js 26.12.1 (also reproduced on 24.10.0 before upgrading) - macOS (Apple Silicon, Homebrew), 32 GB-class host - Target: `app.asar` of a real Electron app (Canva Desktop 1.126.2); the failing source is `dist/main.js` inside the asar ## Steps to reproduce ``` rea analyze-javascript-application /Applications/Canva.app/Contents/Resources/app.asar \ --format json --source-path dist/main.js \ --analysis-timeout-ms 3600000 --max-heap-mb 2048 \ --max-semantic-nodes 2000 --max-semantic-nodes-per-file 2000 \ --max-semantic-unknowns 1000 --max-semantic-unknowns-per-file 1000 ``` ## Attempts | # | analysis-timeout-ms | semantic limits | result | |---|---|---|---| | 1 | 300000 | defaults | timeout in `javascript_worker_semantic` (152-file run; other 151 files fine) | | 2 | 3600000 | defaults | timeout in `javascript_worker_semantic` | | 3 | 3600000 | nodes 2000/file 2000/unknowns 1000 | timeout in `javascript_worker_semantic` | Progress output always reaches `javascript_worker_static: dist/main.js` and then stalls at `javascript_worker_semantic: dist/main.js` until the deadline. ## Expected Either completion, or bounded early exit with partial semantic projection when limits are lowered (attempt 3 sets very low node/unknown caps, yet runtime is unchanged, which suggests unbounded work before projection rather than retention overflow). ## Actual ```json {"code":"provider_timeout","category":"timeout","message":"JavaScript source analysis reached its 3600000ms per-source server/provider deadline (analysis_timeout_ms), not the MCP client deadline.","retryable":true} ``` ## Notes - File size/shape: 6.5 MB, heavily minified, single webpack runtime + bundled modules, no source map - Memory does not appear to be the constraint (`--max-heap-mb 2048`, no OOM); the run is CPU-bound in the semantic worker - Possibly relevant: the bundle contains very large single expressions and deeply nested call chains typical of minified output; if the semantic pass has super-linear behavior on expression depth/size, this input may trigger it - Happy to provide the exact artifact privately if useful; it is a public app bundle (asar of a widely distributed Electron app) Thanks! The static + semantic analysis of the other 151 sources of the same artifact worked beautifully.

bsakaguchi commented

2026-10-31 00:48:36 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 26, 2026):

Thanks for the detailed repro — a 6.5 MB minified webpack bundle is a very common shape for real Electron main processes, so this is far from an edge case for the tool's audience. The key observation that lowering the node/unknown caps does not change runtime strongly suggests the blow-up happens during expression-level traversal (deeply nested call chains typical of minified output) rather than during retention/projection — so the semantic worker likely needs an expression-depth or sub-expression budget in addition to the node counts. A practical interim workaround for users hitting this today would also help a lot (e.g. per-file semantic skip or a static-only fallback for oversized bundles). Happy to help test once a fix or a profiling build is available.

@XinwangTao commented on GitHub (Oct 26, 2026): Thanks for the detailed repro — a 6.5 MB minified webpack bundle is a very common shape for real Electron main processes, so this is far from an edge case for the tool's audience. The key observation that lowering the node/unknown caps does not change runtime strongly suggests the blow-up happens during expression-level traversal (deeply nested call chains typical of minified output) rather than during retention/projection — so the semantic worker likely needs an expression-depth or sub-expression budget in addition to the node counts. A practical interim workaround for users hitting this today would also help a lot (e.g. per-file semantic skip or a static-only fallback for oversized bundles). Happy to help test once a fix or a profiling build is available.

bsakaguchi referenced this issue

2026-10-31 00:49:29 +00:00

[GH-ISSUE #7390] [Bug] Universal signature inspection skips other slice states and its coverage note #4398

bsakaguchi referenced this issue

2026-10-31 00:50:17 +00:00

[GH-ISSUE #7555] [Bug] inspect-signature rejects valid thin arm64e Mach-O files #4496

bsakaguchi referenced this issue

2026-10-31 01:12:39 +00:00

[PR #4359] [CLOSED] fix(native): report every slice of a signed universal Mach-O signature #6202