morluto/rea

Fork 0

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

[GH-ISSUE #7510] [Bug] analyze-javascript-application never completes on a 20 MB Expo Router web bundle, even with semantic limits at 1 #4466

New issue

Open

opened 2026-10-31 00:50:04 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

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

Owner

Originally created by @xyeoda on GitHub (Oct 27, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/7510

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Evidence, artifacts, or reconstruction

Observed behavior

analyze-javascript-application never produces a result for one 20 MB Expo (Metro) web bundle. Each attempt either skips the file or times out with partial Evidence. The last attempt selected only that file, set every semantic retention limit to 1 and asked for the javascript-routes view. It ran for the full 30-minute deadline and the partial Evidence held 0 routes.

Run	Command flags (CLI, `--json`)	Result
1	defaults, `--detail summary --evidence_output …`	Finished in about 20 s. The main bundle was skipped: `Owned JavaScript worker exhausted its 1024 MiB V8 old-space heap (max_heap_mb) while analyzing index-….js during parse`. The other two files were analysed.
2	`--max-heap-mb 6144 --analysis-timeout-ms 900000`	`provider_timeout` after 914 s wall time. `/usr/bin/time -l` max RSS 3.66 GB.
3	`--source-path index-….js --max-semantic-nodes 1 --max-semantic-nodes-per-file 1 --max-semantic-unknowns 1 --max-semantic-unknowns-per-file 1 --max-heap-mb 6144 --analysis-timeout-ms 1800000 --view '{"kind":"javascript-routes","collection":"routes","fields":["path","classification","confidence"],"limit":500}'`	`provider_timeout` after 1804 s. `details.partial_observation.normalized_result.route_inventory.routes` is empty.

The single process sample I took during run 3, about 2m40s in, showed the analyzer worker at 94% CPU and 537 MB RSS. So run 3 looks CPU-bound rather than memory-bound. I took only that one sample.

Reproduction

Each run reproduced once; I did not repeat them.

Take a production Expo Router web export (expo export --platform web) with a large app. Mine has three files in /abs/app:
- index-<hash>.js: 20,029,315 bytes, minified Metro output, 10,365 lines
- __common-<hash>.js: 318,596 bytes
- __expo-metro-runtime-<hash>.js: 3,887 bytes
The target is a third-party app, so I can't attach it. I haven't yet checked whether an Expo Router web export of similar size built from a public template reproduces this.
Run rea analyze-javascript-application /abs/app --source-path index-<hash>.js --max-semantic-nodes 1 --max-semantic-nodes-per-file 1 --max-semantic-unknowns 1 --max-semantic-unknowns-per-file 1 --max-heap-mb 6144 --analysis-timeout-ms 1800000 --detail summary --view '{"kind":"javascript-routes","collection":"routes","limit":500}' --evidence_output /abs/routes.json --json

Expected behavior

The documentation suggests that for a large target, choosing the source and lowering the semantic limits should make the analysis cheaper. See skills/reverse-engineer-anything/references/javascript-applications.md and the --max-semantic-* help text ("Semantic node retention reached … Set max_semantic_nodes_per_file …"). I expected run 3 to return at least the parse-level facts and route candidates within a bounded time, or to report which phase is unbounded. It did not finish in 30 minutes.

For comparison, the route literals are recoverable as plain text. Expo Router's require.context keys such as "./(app)/<section>/[id]/edit.tsx" appear verbatim in the bundle. A plain grep -oE '"\./[^"]+\.tsx"' finds 277 of them in about 1 s. I have not checked whether REA's route detector is meant to recognise this Expo Router pattern.

Impact and scope

Evidence integrity: no problem. REA reported partial coverage honestly every time, and its remediation text was accurate.
Impact: large single-file React Native Web / Expo bundles cannot be analysed at all, and the route inventory comes back empty.
Not tested: other Expo or Metro bundles, Hermes bundles, older REA versions, and the MCP adapter. CLI only.

REA version

6.8.0 (rea-agents from npm)

Runtime and platform

Node.js 24.22.1 (npm node package; host Node was 26.5.0 at the time), macOS 26.6.2, arm64 (Apple silicon)

Target and artifact context

Third-party production Expo Router web export, Metro bundler output: one 20 MB index-*.js plus a common chunk and the metro runtime, analysed as a plain directory. It is not an ASAR or Electron app.

Interface

CLI

Earliest failure stage

Analysis (source analysis of the main bundle). With default limits the failure appears during parse (heap). With higher limits the phase is unknown; the run just reaches the deadline.

Relevant output or evidence

Run 3 stdout (truncated):

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

Partial Evidence limitation: index-<hash>.js: Analysis operation timed out after 1800000ms: analyze_javascript_application. normalized_result.route_inventory.routes has length 0.

Analysis or suspected cause

This is a hypothesis; I have not traced it in the source. Setting the semantic retention limits to 1 did not bound run time, so the cost is probably in a traversal phase that runs before or independently of semantic retention. That would fit #2498 and #4601, scaled up to a 20 MB file.

Additional context

Related: #2498, #4601, #5138, #1565. I found no existing issue about React Native, Expo, Metro or Hermes bundles.

Originally created by @xyeoda on GitHub (Oct 27, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7510 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Evidence, artifacts, or reconstruction ### Observed behavior `analyze-javascript-application` never produces a result for one 20 MB Expo (Metro) web bundle. Each attempt either skips the file or times out with partial Evidence. The last attempt selected only that file, set every semantic retention limit to 1 and asked for the `javascript-routes` view. It ran for the full 30-minute deadline and the partial Evidence held **0 routes**. | Run | Command flags (CLI, `--json`) | Result | |---|---|---| | 1 | defaults, `--detail summary --evidence_output …` | Finished in about 20 s. The main bundle was **skipped**: `Owned JavaScript worker exhausted its 1024 MiB V8 old-space heap (max_heap_mb) while analyzing index-….js during parse`. The other two files were analysed. | | 2 | `--max-heap-mb 6144 --analysis-timeout-ms 900000` | `provider_timeout` after 914 s wall time. `/usr/bin/time -l` max RSS 3.66 GB. | | 3 | `--source-path index-….js --max-semantic-nodes 1 --max-semantic-nodes-per-file 1 --max-semantic-unknowns 1 --max-semantic-unknowns-per-file 1 --max-heap-mb 6144 --analysis-timeout-ms 1800000 --view '{"kind":"javascript-routes","collection":"routes","fields":["path","classification","confidence"],"limit":500}'` | `provider_timeout` after 1804 s. `details.partial_observation.normalized_result.route_inventory.routes` is empty. | The single process sample I took during run 3, about 2m40s in, showed the analyzer worker at 94% CPU and 537 MB RSS. So run 3 looks CPU-bound rather than memory-bound. I took only that one sample. ### Reproduction Each run reproduced once; I did not repeat them. 1. Take a production Expo Router web export (`expo export --platform web`) with a large app. Mine has three files in `/abs/app`: - `index-<hash>.js`: 20,029,315 bytes, minified Metro output, 10,365 lines - `__common-<hash>.js`: 318,596 bytes - `__expo-metro-runtime-<hash>.js`: 3,887 bytes The target is a third-party app, so I can't attach it. I haven't yet checked whether an Expo Router web export of similar size built from a public template reproduces this. 2. Run `rea analyze-javascript-application /abs/app --source-path index-<hash>.js --max-semantic-nodes 1 --max-semantic-nodes-per-file 1 --max-semantic-unknowns 1 --max-semantic-unknowns-per-file 1 --max-heap-mb 6144 --analysis-timeout-ms 1800000 --detail summary --view '{"kind":"javascript-routes","collection":"routes","limit":500}' --evidence_output /abs/routes.json --json` ### Expected behavior The documentation suggests that for a large target, choosing the source and lowering the semantic limits should make the analysis cheaper. See `skills/reverse-engineer-anything/references/javascript-applications.md` and the `--max-semantic-*` help text ("Semantic node retention reached … Set max_semantic_nodes_per_file …"). I expected run 3 to return at least the parse-level facts and route candidates within a bounded time, or to report which phase is unbounded. It did not finish in 30 minutes. For comparison, the route literals are recoverable as plain text. Expo Router's `require.context` keys such as `"./(app)/<section>/[id]/edit.tsx"` appear verbatim in the bundle. A plain `grep -oE '"\./[^"]+\.tsx"'` finds 277 of them in about 1 s. I have not checked whether REA's route detector is meant to recognise this Expo Router pattern. ### Impact and scope - **Evidence integrity:** no problem. REA reported partial coverage honestly every time, and its remediation text was accurate. - **Impact:** large single-file React Native Web / Expo bundles cannot be analysed at all, and the route inventory comes back empty. - **Not tested:** other Expo or Metro bundles, Hermes bundles, older REA versions, and the MCP adapter. CLI only. ### REA version 6.8.0 (`rea-agents` from npm) ### Runtime and platform Node.js 24.22.1 (npm `node` package; host Node was 26.5.0 at the time), macOS 26.6.2, arm64 (Apple silicon) ### Target and artifact context Third-party production Expo Router web export, Metro bundler output: one 20 MB `index-*.js` plus a common chunk and the metro runtime, analysed as a plain directory. It is not an ASAR or Electron app. ### Interface CLI ### Earliest failure stage Analysis (source analysis of the main bundle). With default limits the failure appears during parse (heap). With higher limits the phase is unknown; the run just reaches the deadline. ### Relevant output or evidence Run 3 stdout (truncated): ```json {"error":"JavaScript application analysis failed","code":"provider_timeout","category":"timeout","message":"JavaScript source analysis reached its 1800000ms per-source server/provider deadline (analysis_timeout_ms), not the MCP client deadline.","retryable":true, ...} ``` Partial Evidence limitation: `index-<hash>.js: Analysis operation timed out after 1800000ms: analyze_javascript_application`. `normalized_result.route_inventory.routes` has length 0. ### Analysis or suspected cause This is a hypothesis; I have not traced it in the source. Setting the semantic retention limits to 1 did not bound run time, so the cost is probably in a traversal phase that runs before or independently of semantic retention. That would fit #2498 and #4601, scaled up to a 20 MB file. ### Additional context Related: #2498, #4601, #5138, #1565. I found no existing issue about React Native, Expo, Metro or Hermes bundles.

bsakaguchi referenced this issue

2026-10-31 01:13:05 +00:00

[PR #4466] [MERGED] feat(android): make the JADX operation deadline configurable #6259

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

No description provided.

Rows
Columns