morluto/rea

Fork 0

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

[GH-ISSUE #746] analyze-javascript-application: zero output for minutes then generic unreadable_output failure on a 24 MB Electron ASAR (Obsidian 1.12.7) #331

New issue

Closed

opened 2026-10-15 18:24:00 +00:00 by bsakaguchi · 4 comments

bsakaguchi commented

2026-10-15 18:24:00 +00:00

Owner

Originally created by @raphaelraphbone-jpg on GitHub (Oct 6, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/746

Originally assigned to: @N0zoM1z0, @kaoru0822-kitauji on GitHub.

Summary

rea analyze-javascript-application on Obsidian's application archive (obsidian.asar, 24,060,763 bytes, Obsidian 1.12.7) is completely silent — zero bytes on stdout and stderr — for minutes, then (on the current release) terminates with a generic typed error that names no cause:

error: JavaScript application analysis failed
code: unreadable_output
category: execution_failure
message: "Analysis returned an unreadable result. Retry once; if it continues, run `rea doctor`."
retryable: false
remediation:
  action: "Analysis returned an unreadable result. Retry once; if it continues, run `rea doctor`."

The same command against the 74 KB Electron loader archive (app.asar) of the same app reaches a precise typed verdict (an integrity mismatch with logical path and both sha256 hashes) in seconds. On the large archive: no progress output at any point, and a final error that makes the failure undiagnosable without running rea doctor and rea's own debug tooling.

Observation windows: on rea-agents 3.2.1 the silence was still unbroken at ≥15 min (run 1) and ≥3 min (run 2, killed by operator), i.e. no terminal state was reached within those windows; on rea-agents 4.0.1 (current, 2/2 runs) the same command fails with unreadable_output at ~4.5–5 min.

Environment

rea-agents 3.2.1 (isolated npm prefix, installed 2026-10-05) — runs 1–2
rea-agents 4.0.1 (fresh isolated npm prefix, installed 2026-10-06, rea --version verified) — runs 3–4
Node v26.8.1; macOS 15.7.7 (arm64)
Target: /Applications/Obsidian.app/Contents/Resources/obsidian.asar — Obsidian 1.12.7, 24,060,763 bytes (size re-verified unchanged on 2026-10-06 after run 1)

Reproduction

Install the pinned package into an isolated prefix:

npm install --prefix <isolated-dir> rea-agents@4.0.1

Run:

rea analyze-javascript-application /Applications/Obsidian.app/Contents/Resources/obsidian.asar --token-limit 500

Observe: the process stays alive and emits nothing for ~4.5–5 minutes, then exits with the unreadable_output block above. The captured process logs are empty from offset 0 until the error appears (rules out an interactive prompt or swallowed progress output).

run	when (BST)	rea-agents	observed window	outcome
1	2026-10-06 ~01:44	3.2.1	≥15 min	no output at any point; session ended before an observed termination
2	2026-10-06 ~15:3x	3.2.1	3+ min	no output; killed by operator
3	2026-10-06 ~16:27	4.0.1	~4.5–5 min silent	`unreadable_output`, exit 1 (emitted before the 300 s harness cap; confirmed genuine exit, see run 4)
4	2026-10-06 ~16:34	4.0.1	~4.5–5 min silent	identical `unreadable_output`, exit 1, under a 900 s cap — genuine terminal state, 2/2 reproducible

Runs 3–4 used identical commands/binary/payload; both produced the same error. The 900 s cap on run 4 exists to distinguish a genuine exit from a timeout kill and was never reached.

Controls (same host, same day)

Everything else tried completes in seconds:

managed-PE operations on Unity DLLs: inspect-managed-artifact, members, compare
native-macos operations on Obsidian.app itself: inspect-macho, inspect-signature, inspect-plist
The identical command form against the 74 KB loader archive app.asar reaches a typed terminal state in seconds on both 3.2.1 and 4.0.1 — same CLI path, same provider boot, precise diagnosis (next section).

Contrast: the small loader archive gets a precise typed verdict in seconds

On 4.0.1 (and identically on 3.2.1 re-run the same day), the identical command form against the 74 KB loader archive exits quickly with a typed integrity error (exit code 1):

code: artifact_integrity_mismatch
logical_path: node_modules/btime/bin/darwin-x64-101/btime.node
declared_sha256:    ed5cb9d0430b9dfb5cc9754bb46c2f6023c63451d625354bcf9f2a512ff49f5b
calculated_sha256:  4f41788bc717b0cf4efb5680a2d76dc9ab827625b70075439ad2fca3a1a7bf67
unpacked: true

The calculated hash was independently confirmed with shasum -a 256 — the on-disk file genuinely differs from the archive's declared hash (plausibly an updater/packaging artifact; no tampering claim intended). That fail-closed verdict is expected behavior per #112's design and is not the subject of this report. It is included only as contrast: the same binary, on the tiny archive, produces a precise typed error naming the entry and both hashes within seconds — while the 24 MB archive yields minutes of silence and a cause-free unreadable_output.

#623 (open) — analyze_javascript_application on large JS trees fails fast (~121 s on 2.91 MB of JS) with RangeError: Invalid string length masked as reason:"io", and its "Related: CLI output path" section documents the full-result print path throwing in JSON.stringify on oversized envelopes. Interpretation only, not verified here: a 24 MB ASAR produces a semantic graph an order of magnitude beyond those sizes, and unreadable_output is consistent with the giant-envelope/materialization class that #623 analyzes — but this report's evidence covers only the observed behavior, not the root cause.

Impact

The flagship large-target use case (big Electron payloads, per #623) is unusable: for ~5 minutes the CLI gives no signal distinguishing a live analysis from a hang, then the terminal error (unreadable_output) names no subsystem, no artifact, no cause — the only suggested remedy is a non-specific "retry once, run rea doctor".
The silence + generic terminal state together effectively force external process tooling (background capture, byte-level log checks) to diagnose at all — the very thing the typed-error design (per #112, #100) is meant to avoid.

Suggested direction (non-prescriptive)

Surface early bounded progress (entries-scanned / provider phase) or a typed start-of-analysis status line so silence is interpretable.
Make unreadable_output carry its underlying cause (or a structured details payload), mirroring the masking-diagnosis in #623 — e.g. whether the analysis graph or its output serialization failed.

Happy to provide: full captured process logs (empty from offset 0 until the terminal error, all four runs), exact npm prefix paths, per-run timestamps and cap settings, and the shasum receipt for btime.node.

Single-observation caveats

Run 1's process state beyond ≥15 min of silence was never observed (the host session ended first); run 2 was operator-killed at 3+ min. Only runs 3–4 establish the current-release terminal behavior, which they do identically (2/2).
No memory/CPU profiling was attached; the report claims only the output/termination signature, not the internal cause.

Originally created by @raphaelraphbone-jpg on GitHub (Oct 6, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/746 Originally assigned to: @N0zoM1z0, @kaoru0822-kitauji on GitHub. ### Summary `rea analyze-javascript-application` on Obsidian's application archive (`obsidian.asar`, 24,060,763 bytes, Obsidian 1.12.7) is **completely silent — zero bytes on stdout and stderr — for minutes**, then (on the current release) terminates with a generic typed error that names no cause: ``` error: JavaScript application analysis failed code: unreadable_output category: execution_failure message: "Analysis returned an unreadable result. Retry once; if it continues, run `rea doctor`." retryable: false remediation: action: "Analysis returned an unreadable result. Retry once; if it continues, run `rea doctor`." ``` The same command against the 74 KB Electron loader archive (`app.asar`) of the same app reaches a **precise** typed verdict (an integrity mismatch with logical path and both sha256 hashes) in seconds. On the large archive: no progress output at any point, and a final error that makes the failure undiagnosable without running `rea doctor` and rea's own debug tooling. Observation windows: on rea-agents 3.2.1 the silence was still unbroken at ≥15 min (run 1) and ≥3 min (run 2, killed by operator), i.e. no terminal state was reached within those windows; on rea-agents 4.0.1 (current, 2/2 runs) the same command fails with `unreadable_output` at ~4.5–5 min. ### Environment - rea-agents 3.2.1 (isolated npm prefix, installed 2026-10-05) — runs 1–2 - rea-agents 4.0.1 (fresh isolated npm prefix, installed 2026-10-06, `rea --version` verified) — runs 3–4 - Node v26.8.1; macOS 15.7.7 (arm64) - Target: `/Applications/Obsidian.app/Contents/Resources/obsidian.asar` — Obsidian 1.12.7, 24,060,763 bytes (size re-verified unchanged on 2026-10-06 after run 1) ### Reproduction 1. Install the pinned package into an isolated prefix: ``` npm install --prefix <isolated-dir> rea-agents@4.0.1 ``` 2. Run: ``` rea analyze-javascript-application /Applications/Obsidian.app/Contents/Resources/obsidian.asar --token-limit 500 ``` 3. Observe: the process stays alive and emits **nothing** for ~4.5–5 minutes, then exits with the `unreadable_output` block above. The captured process logs are empty from offset 0 until the error appears (rules out an interactive prompt or swallowed progress output). | run | when (BST) | rea-agents | observed window | outcome | |---|---|---|---|---| | 1 | 2026-10-06 ~01:44 | 3.2.1 | ≥15 min | no output at any point; session ended before an observed termination | | 2 | 2026-10-06 ~15:3x | 3.2.1 | 3+ min | no output; killed by operator | | 3 | 2026-10-06 ~16:27 | 4.0.1 | ~4.5–5 min silent | `unreadable_output`, exit 1 (emitted before the 300 s harness cap; confirmed genuine exit, see run 4) | | 4 | 2026-10-06 ~16:34 | 4.0.1 | ~4.5–5 min silent | identical `unreadable_output`, exit 1, under a 900 s cap — genuine terminal state, 2/2 reproducible | Runs 3–4 used identical commands/binary/payload; both produced the same error. The 900 s cap on run 4 exists to distinguish a genuine exit from a timeout kill and was never reached. ### Controls (same host, same day) Everything else tried completes in seconds: - managed-PE operations on Unity DLLs: `inspect-managed-artifact`, members, compare - native-macos operations on Obsidian.app itself: `inspect-macho`, `inspect-signature`, `inspect-plist` - The identical command form against the 74 KB loader archive `app.asar` reaches a typed terminal state in seconds on **both** 3.2.1 and 4.0.1 — same CLI path, same provider boot, precise diagnosis (next section). ### Contrast: the small loader archive gets a precise typed verdict in seconds On 4.0.1 (and identically on 3.2.1 re-run the same day), the identical command form against the 74 KB loader archive exits quickly with a typed integrity error (exit code 1): ``` code: artifact_integrity_mismatch logical_path: node_modules/btime/bin/darwin-x64-101/btime.node declared_sha256: ed5cb9d0430b9dfb5cc9754bb46c2f6023c63451d625354bcf9f2a512ff49f5b calculated_sha256: 4f41788bc717b0cf4efb5680a2d76dc9ab827625b70075439ad2fca3a1a7bf67 unpacked: true ``` The calculated hash was independently confirmed with `shasum -a 256` — the on-disk file genuinely differs from the archive's declared hash (plausibly an updater/packaging artifact; no tampering claim intended). That fail-closed verdict is expected behavior per #112's design and is **not** the subject of this report. It is included only as contrast: the same binary, on the tiny archive, produces a precise typed error naming the entry and both hashes within seconds — while the 24 MB archive yields minutes of silence and a cause-free `unreadable_output`. ### Related - #623 (open) — `analyze_javascript_application` on large JS trees fails fast (~121 s on 2.91 MB of JS) with `RangeError: Invalid string length` masked as `reason:"io"`, and its "Related: CLI output path" section documents the full-result print path throwing in `JSON.stringify` on oversized envelopes. *Interpretation only, not verified here:* a 24 MB ASAR produces a semantic graph an order of magnitude beyond those sizes, and `unreadable_output` is consistent with the giant-envelope/materialization class that #623 analyzes — but this report's evidence covers only the observed behavior, not the root cause. ### Impact - The flagship large-target use case (big Electron payloads, per #623) is unusable: for ~5 minutes the CLI gives no signal distinguishing a live analysis from a hang, then the terminal error (`unreadable_output`) names no subsystem, no artifact, no cause — the only suggested remedy is a non-specific "retry once, run `rea doctor`". - The silence + generic terminal state together effectively force external process tooling (background capture, byte-level log checks) to diagnose at all — the very thing the typed-error design (per #112, #100) is meant to avoid. ### Suggested direction (non-prescriptive) - Surface early bounded progress (entries-scanned / provider phase) or a typed start-of-analysis status line so silence is interpretable. - Make `unreadable_output` carry its underlying cause (or a structured details payload), mirroring the masking-diagnosis in #623 — e.g. whether the analysis graph or its output serialization failed. Happy to provide: full captured process logs (empty from offset 0 until the terminal error, all four runs), exact npm prefix paths, per-run timestamps and cap settings, and the `shasum` receipt for `btime.node`. ### Single-observation caveats - Run 1's process state beyond ≥15 min of silence was never observed (the host session ended first); run 2 was operator-killed at 3+ min. Only runs 3–4 establish the current-release terminal behavior, which they do identically (2/2). - No memory/CPU profiling was attached; the report claims only the output/termination signature, not the internal cause.

bsakaguchi

2026-10-15 18:24:00 +00:00

closed this issue
added the
area: cli

bug
labels

bsakaguchi commented

2026-10-15 18:24:01 +00:00

Author

Owner

@gustavczar commented on GitHub (Oct 7, 2026):

Root cause candidate plus a minimal repro. On 4.1.0, unreadable_output now carries a details.reason, and that reason points at empty string literals.

Same failure on Windows, with the reason exposed

obsidian.asar (27,477,966 bytes, Obsidian.exe 1.14.4), Windows 11 x64, Node 22.23.2:

build	time	`details.reason`
`rea-agents@4.1.0` (npm)	~16 min	`Result schema rejected 2 issues at /identity/key (too_small)`
source `50787b2f`	~10 min	same

Minimal repro: one empty string literal fails the whole analysis in seconds

Each case is a directory with package.json = { "name": "r", "version": "1.0.0", "main": "main.js" } and a one-line main.js:

case	`main.js`	`details.reason`
fetch	`fetch("");`	`2 issues at /identity/key (too_small)`
loadurl	`const { BrowserWindow } = require("electron"); new BrowserWindow().loadURL("");`	`2 issues at /identity/key (too_small)`
storage	`localStorage.getItem(""); localStorage.setItem("", "v");`	`2 issues at /identity/key (too_small)`
ipc-main	`const { ipcMain } = require("electron"); ipcMain.handle("", async () => 1);`	`1 issue at /observations/0/label (too_small)`
ipc-renderer	`const { ipcRenderer } = require("electron"); ipcRenderer.send("");`	`1 issue at /observations/0/label (too_small)`
loadfile	`const { BrowserWindow } = require("electron"); new BrowserWindow().loadFile("");`	`1 issue at /observations/0/label (too_small)`
expose	`const { contextBridge } = require("electron"); contextBridge.exposeInMainWorld("", {});`	`1 issue at /observations/0/label (too_small)`
require-empty	`const x = require("");`	`1 issue at /observations/0/label (too_small)`
dyn-import	`import("").then(() => 0);`	`1 issue at /observations/0/label (too_small)`

rea analyze-javascript-application <case-dir> --json
→ code: unreadable_output, details.reason as above

All 9 results are identical on rea-agents@4.1.0, on main at 472b72a5, and on PR #764 (pr-764 head). As a control, a 5-file Electron app using ipcMain.handle, ipcRenderer.invoke, contextBridge.exposeInMainWorld, loadFile and require with non-empty literals returns Evidence on all three builds.

The Obsidian signature (2 issues at /identity/key) matches the fetch / loadURL / localStorage cases exactly. I did not confirm which literal in the minified bundle triggers it. A 24-27 MB real-world bundle containing at least one "" in one of these positions is very likely, which would also explain why the run gets all the way through the graph before failing.

Where it seems to come from

artifactLocalIdentity(sha256, namespace, key) (src/application/JavaScriptArtifactGraphContext.ts) passes the literal straight through as key. The output schema (applicationNodeIdentitySchema, variant artifact-local-key, in src/domain/javascriptApplicationEvidenceSchemas.ts) requires a non-empty key, and node and observation labels are likewise required to be non-empty. So a legal empty literal produces a node that the result validator rejects, and the whole result is discarded as unreadable_output.

PR #764 fixes the same class of bug for empty property keys in the semantic graph ({'': 'HOME'}), but these producers (Electron boundary / findings / module relationships) are separate and still fail on that branch.

Possible directions, in case they help:

encode the empty literal in identity keys and labels, for example as "", the same way #764 displays the empty property slot; or
drop or mark these observations as unknown instead of failing the whole result; at minimum, include the node kind and module path in details so the failure points at the offending source.

@gustavczar commented on GitHub (Oct 7, 2026): Root cause candidate plus a minimal repro. On 4.1.0, `unreadable_output` now carries a `details.reason`, and that reason points at **empty string literals**. ### Same failure on Windows, with the reason exposed `obsidian.asar` (27,477,966 bytes, `Obsidian.exe` 1.14.4), Windows 11 x64, Node 22.23.2: | build | time | `details.reason` | |---|---|---| | `rea-agents@4.1.0` (npm) | ~16 min | `Result schema rejected 2 issues at /identity/key (too_small)` | | source `50787b2f` | ~10 min | same | ### Minimal repro: one empty string literal fails the whole analysis in seconds Each case is a directory with `package.json` = `{ "name": "r", "version": "1.0.0", "main": "main.js" }` and a one-line `main.js`: | case | `main.js` | `details.reason` | |---|---|---| | fetch | `fetch("");` | `2 issues at /identity/key (too_small)` | | loadurl | `const { BrowserWindow } = require("electron"); new BrowserWindow().loadURL("");` | `2 issues at /identity/key (too_small)` | | storage | `localStorage.getItem(""); localStorage.setItem("", "v");` | `2 issues at /identity/key (too_small)` | | ipc-main | `const { ipcMain } = require("electron"); ipcMain.handle("", async () => 1);` | `1 issue at /observations/0/label (too_small)` | | ipc-renderer | `const { ipcRenderer } = require("electron"); ipcRenderer.send("");` | `1 issue at /observations/0/label (too_small)` | | loadfile | `const { BrowserWindow } = require("electron"); new BrowserWindow().loadFile("");` | `1 issue at /observations/0/label (too_small)` | | expose | `const { contextBridge } = require("electron"); contextBridge.exposeInMainWorld("", {});` | `1 issue at /observations/0/label (too_small)` | | require-empty | `const x = require("");` | `1 issue at /observations/0/label (too_small)` | | dyn-import | `import("").then(() => 0);` | `1 issue at /observations/0/label (too_small)` | ``` rea analyze-javascript-application <case-dir> --json → code: unreadable_output, details.reason as above ``` All 9 results are identical on `rea-agents@4.1.0`, on `main` at `472b72a5`, and on PR #764 (`pr-764` head). As a control, a 5-file Electron app using `ipcMain.handle`, `ipcRenderer.invoke`, `contextBridge.exposeInMainWorld`, `loadFile` and `require` with **non-empty** literals returns Evidence on all three builds. The Obsidian signature (`2 issues at /identity/key`) matches the `fetch` / `loadURL` / `localStorage` cases exactly. I did not confirm which literal in the minified bundle triggers it. A 24-27 MB real-world bundle containing at least one `""` in one of these positions is very likely, which would also explain why the run gets all the way through the graph before failing. ### Where it seems to come from `artifactLocalIdentity(sha256, namespace, key)` (`src/application/JavaScriptArtifactGraphContext.ts`) passes the literal straight through as `key`. The output schema (`applicationNodeIdentitySchema`, variant `artifact-local-key`, in `src/domain/javascriptApplicationEvidenceSchemas.ts`) requires a non-empty `key`, and node and observation labels are likewise required to be non-empty. So a legal empty literal produces a node that the result validator rejects, and the whole result is discarded as `unreadable_output`. PR #764 fixes the same class of bug for empty **property keys** in the semantic graph (`{'': 'HOME'}`), but these producers (Electron boundary / findings / module relationships) are separate and still fail on that branch. Possible directions, in case they help: - encode the empty literal in identity keys and labels, for example as `""`, the same way #764 displays the empty property slot; or - drop or mark these observations as unknown instead of failing the whole result; at minimum, include the node kind and module path in `details` so the failure points at the offending source.

bsakaguchi commented

2026-10-15 18:24:01 +00:00

Author

Owner

@raphaelraphbone-jpg commented on GitHub (Oct 7, 2026):

Confirming the analysis independently on macOS — and noting this class is now fixed and released.

Independent confirmation (macOS 15.7.7 arm64, Node v26.8.1, rea-agents@4.1.0): all 9 minimal cases from the table reproduce with identical details.reason strings — fetch/loadURL/localStorage → 2 issues at /identity/key (too_small), the other six → 1 issue at /observations/0/label (too_small) — each failing in seconds. Non-empty controls (fetch/localStorage/4-file Electron app) return Evidence. The original case in this issue is ours (obsidian.asar, 24,060,763 bytes, Obsidian 1.12.7): on 4.1.0 it now fails with Result schema rejected 2 issues at /identity/key (too_small) — the fetch/loadURL/localStorage class; on 4.0.1 the same input produced only the silent generic unreadable_output, so #749's diagnostics are what made this root-cause hunt possible.

Fix status, verified from source and now in the 5.0.0 release: rebuilt from current main (ef1a0cc6): fetch("") and ipcMain.handle("") both return full Evidence with the exact empty value preserved (key: "", observation label null, "" display in the semantic graph) — consistent with the #839 seam-normalization series and the JavaScriptApplicationEmptyLiterals test suite covering all nine positions; fetch(""), ipcMain.handle(""), and the non-empty Electron controls also pass on the published rea-agents@5.0.0.

As reinforcement of the "at minimum" ask above: a details.reason that also names the offending node kind and module path would turn the next hunt like this into a five-minute one.

Thanks @gustavczar — the minimal repro turned full verification into a ten-minute job.

@raphaelraphbone-jpg commented on GitHub (Oct 7, 2026): Confirming the analysis independently on macOS — and noting this class is now fixed and released. **Independent confirmation** (macOS 15.7.7 arm64, Node v26.8.1, `rea-agents@4.1.0`): all 9 minimal cases from the table reproduce with identical `details.reason` strings — fetch/loadURL/localStorage → `2 issues at /identity/key (too_small)`, the other six → `1 issue at /observations/0/label (too_small)` — each failing in seconds. Non-empty controls (fetch/localStorage/4-file Electron app) return Evidence. The original case in this issue is ours (`obsidian.asar`, 24,060,763 bytes, Obsidian 1.12.7): on 4.1.0 it now fails with `Result schema rejected 2 issues at /identity/key (too_small)` — the fetch/loadURL/localStorage class; on 4.0.1 the same input produced only the silent generic `unreadable_output`, so #749's diagnostics are what made this root-cause hunt possible. **Fix status, verified from source and now in the 5.0.0 release:** rebuilt from current main (`ef1a0cc6`): `fetch("")` and `ipcMain.handle("")` both return full Evidence with the exact empty value preserved (`key: ""`, observation label `null`, `""` display in the semantic graph) — consistent with the #839 seam-normalization series and the `JavaScriptApplicationEmptyLiterals` test suite covering all nine positions; `fetch("")`, `ipcMain.handle("")`, and the non-empty Electron controls also pass on the published `rea-agents@5.0.0`. As reinforcement of the "at minimum" ask above: a `details.reason` that also names the offending node kind and module path would turn the next hunt like this into a five-minute one. Thanks @gustavczar — the minimal repro turned full verification into a ten-minute job.

bsakaguchi commented

2026-10-15 18:24:01 +00:00

Author

Owner

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

Merged in #1055 at b9fb43883570bef7cb29fd16f27c25d5a7e5bb54 after self-review and all 22 CI jobs passed, including Linux x64/arm64, macOS Intel/arm64 and Windows package lanes, plus the separate real JavaScript recovery check.

The official Obsidian 1.12.7 ASAR (24,060,763 bytes, SHA-256 2b2483b2e1246772e0d25367ec055cbc5047ea2f0091b667c35656678f86d712) now completes through the full JSONL CLI path under a 1.5 GiB heap and two CPU affinity: 162.3 s on Linux and 185.9 s using the installed package on Windows. Peak analysis-process RSS was approximately 1.58 GiB and 1.39 GiB respectively. Complete output was independently streamed through a JSON parser; graph IDs and all counts match across those platforms. Full shipped Notion also passes. Existing semantic coverage remains partial under the existing node budget, and the target code is never executed.

rea analyze-javascript-application <selected.asar> --format jsonl

The change projects semantics file by file, indexes source-range relationships, avoids rejected-node and duplicate-payload allocations, and emits per-file progress with cancellation checks between files. Measurements, complete-result parity and the original macOS coverage limitation are recorded in #1055. This is a source-main fix; no new npm release was published by this work. The independent large MCP serialization failure remains tracked in #1053, with result-view work in #1050.

@N0zoM1z0 commented on GitHub (Oct 8, 2026): Merged in #1055 at `b9fb43883570bef7cb29fd16f27c25d5a7e5bb54` after self-review and all 22 CI jobs passed, including Linux x64/arm64, macOS Intel/arm64 and Windows package lanes, plus the separate real JavaScript recovery check. The official Obsidian 1.12.7 ASAR (24,060,763 bytes, SHA-256 `2b2483b2e1246772e0d25367ec055cbc5047ea2f0091b667c35656678f86d712`) now completes through the full JSONL CLI path under a 1.5 GiB heap and two CPU affinity: 162.3 s on Linux and 185.9 s using the installed package on Windows. Peak analysis-process RSS was approximately 1.58 GiB and 1.39 GiB respectively. Complete output was independently streamed through a JSON parser; graph IDs and all counts match across those platforms. Full shipped Notion also passes. Existing semantic coverage remains partial under the existing node budget, and the target code is never executed. ```sh rea analyze-javascript-application <selected.asar> --format jsonl ``` The change projects semantics file by file, indexes source-range relationships, avoids rejected-node and duplicate-payload allocations, and emits per-file progress with cancellation checks between files. Measurements, complete-result parity and the original macOS coverage limitation are recorded in #1055. This is a source-main fix; no new npm release was published by this work. The independent large MCP serialization failure remains tracked in #1053, with result-view work in #1050.

bsakaguchi commented

2026-10-15 18:24:02 +00:00

Author

Owner

@raphaelraphbone-jpg commented on GitHub (Oct 8, 2026):

Closing the loop from our side: we re-ran the #746 input on the released npm build and can confirm the fix end to end.

Input identity: the ASAR on our host hashes to 2b2483b2e1246772e0d25367ec055cbc5047ea2f0091b667c35656678f86d712 — matching the official-release digest recorded above, which also resolves the byte-identity caveat in the measurement notes: the #746 report came from this same official file.

Result on macOS 15.7.7 arm64, Node v26.8.1, rea-agents@6.0.0 (npm), default old-space heap, no flags beyond --format jsonl:

rea analyze-javascript-application obsidian.asar --format jsonl → exit 0, complete single-record JSONL in 86 s wall, 429,165,788 bytes ≈ 409.2 MiB, consistent with your streamed-output size. Not 1:1 comparable to your two-CPU / below-normal-priority / 1.5 GiB-heap timings (stock all-core M-series, ~4.1 GB default heap, no overrides) — but the salient point is that it completes at default settings where pre-#1055 builds exceeded a ~4.13 GB default heap with no payload.
Statistics extracted from our output match your published figures exactly: 100,000 semantic nodes, 77,137 relations, 144,053 unknowns, 23,440 fingerprints.
IDs from our output, for cross-check against your Linux/Windows runs: application graph root jag_node_d0ce3cd4041ac78e7a978721b3bda854f8f6e7878b65f8b8cc46e25633d2aa41; semantic graph jsrg_5d00550732f58d166315a5192273f4b5c77915fa8fab2c32ca9e99c8cf05d3c4; inventory manifest agm_972efa6b98e133664d362a80346f2cd234dc9ef2f1ce69f5ebeca3383092b246; inventory graph sha256 dea61728f592c171c228f694d644b73e0cac06453818044464529c427e455b17.
stderr carried the per-file projection progress (36 sources, sequences 1–44, terminal marker), and semantic coverage remains partial under the node budget exactly as documented.

Thread history for completeness: this same input exited unreadable_output on 4.1.0 (empty-literal schema void — our earlier comment) and OOM'd past Node's ~4.13 GB default old-space heap on pre-#1055 main with no result payload. On 6.0.0 it completes on default heap out of the box.

Thanks — verified as described on macOS arm64. Watching #1053 (large MCP serialization) and #1050 (result view).

@raphaelraphbone-jpg commented on GitHub (Oct 8, 2026): Closing the loop from our side: we re-ran the #746 input on the released npm build and can confirm the fix end to end. **Input identity:** the ASAR on our host hashes to `2b2483b2e1246772e0d25367ec055cbc5047ea2f0091b667c35656678f86d712` — matching the official-release digest recorded above, which also resolves the byte-identity caveat in the measurement notes: the #746 report came from this same official file. **Result on macOS 15.7.7 arm64, Node v26.8.1, `rea-agents@6.0.0` (npm), default old-space heap, no flags beyond `--format jsonl`:** - `rea analyze-javascript-application obsidian.asar --format jsonl` → **exit 0, complete single-record JSONL in 86 s wall**, 429,165,788 bytes ≈ 409.2 MiB, consistent with your streamed-output size. Not 1:1 comparable to your two-CPU / below-normal-priority / 1.5 GiB-heap timings (stock all-core M-series, ~4.1 GB default heap, no overrides) — but the salient point is that it completes at *default* settings where pre-#1055 builds exceeded a ~4.13 GB default heap with no payload. - Statistics extracted from our output match your published figures exactly: **100,000 semantic nodes, 77,137 relations, 144,053 unknowns, 23,440 fingerprints.** - IDs from our output, for cross-check against your Linux/Windows runs: application graph root `jag_node_d0ce3cd4041ac78e7a978721b3bda854f8f6e7878b65f8b8cc46e25633d2aa41`; semantic graph `jsrg_5d00550732f58d166315a5192273f4b5c77915fa8fab2c32ca9e99c8cf05d3c4`; inventory manifest `agm_972efa6b98e133664d362a80346f2cd234dc9ef2f1ce69f5ebeca3383092b246`; inventory graph sha256 `dea61728f592c171c228f694d644b73e0cac06453818044464529c427e455b17`. - stderr carried the per-file projection progress (`36` sources, sequences 1–44, terminal marker), and semantic coverage remains partial under the node budget exactly as documented. Thread history for completeness: this same input exited `unreadable_output` on 4.1.0 (empty-literal schema void — our earlier comment) and OOM'd past Node's ~4.13 GB default old-space heap on pre-#1055 main with no result payload. On 6.0.0 it completes on default heap out of the box. Thanks — verified as described on macOS arm64. Watching #1053 (large MCP serialization) and #1050 (result view).

bsakaguchi referenced this issue

2026-10-16 21:12:59 +00:00

[PR #424] [MERGED] feat: expand reactive capture and package analysis #1973

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

No description provided.

Rows
Columns