analyze_javascript_application ran several long phases with no event-loop
turn, so MCP ping and cancellation waited: each file's parse, analysis and
semantic projection; building every application node and relationship
before the application graph's first sealing step; and whole-graph schema
parses inside both immutable graph factories.
- Each file runs as steps (parse, static analysis, semantic analysis, then
each projection pass), driven by the existing time-sliced checkpoint.
- Application graph input construction yields between phases, per module
link and per file of findings.
- The pipeline transfers its privately built graph inputs to new sealing
steps that validate the graph's own fields synchronously and elements,
content checks and the digest in steps. The public copying factories
keep their synchronous capture.
Results are unchanged: graph IDs and the complete result digest match main
on five inputs including Obsidian's 23 MB obsidian.asar. On the issue's
1,200-function fixture the longest event-loop block falls from about
290 ms to 90 ms, and ping after abort from up to 286 ms to at most 56 ms.
On obsidian.asar it falls from 10.9 s to 5.4 s; the rest is one analyzer
stage of a single very large file.
Refs #1462
Co-authored-by: Claude Opus 5.5 <[email protected]>
Co-authored-by: N0zoM1z0 <[email protected]>
Intern shared provenance in a graph-scoped context registry while retaining exact locations on every fact. Semantic traces carry their referenced context subset, and portable graph validation rejects stale or dangling commitments.
BREAKING CHANGE: Semantic graph facts now store evidence context IDs and locations. Graph and semantic trace results require an inline evidence_contexts table.
* fix(javascript): bound semantic node projection for resource safety
analyze_javascript_application exhausted the heap or failed serialization on
ordinary inputs. A small extracted tree crashed outright, and a larger
application tree failed at both the default heap and an 8 GB heap.
Cause: the semantic projection emits one node per AST expression, call site,
binding and property slot, with no ceiling. A five-file tree already yields on
the order of 170,000 nodes, and the whole result is serialized after the object
graph is built and validated. Result ceilings were deliberately removed upstream,
so nothing bounded this growth.
Apply two resource-safety ceilings and report them through the graph's own
coverage contract rather than dropping data silently:
- SEMANTIC_GRAPH_NODE_CEILING bounds retained nodes per tree (100,000, roughly
300 MB serialized, below V8's 512 MB string limit).
- SEMANTIC_GRAPH_FILE_NODE_CEILING bounds each source file (20,000) so one
bundled library cannot starve the application's own modules.
Exhausting either marks coverage truncated with a partial status and records the
ceiling in coverage.limits. A small application stays complete and untruncated.
Verified: a previously-crashing application tree now returns Evidence in under a
minute, while a small tree stays complete. Existing tests and check:fast pass.
* fix(javascript): report semantic graph truncation accurately
---------
Co-authored-by: REA Contributor <[email protected]>
Co-authored-by: morluto <[email protected]>
