JS/TS: `affected` cannot traverse a dynamic `import('…')` made inside a function — edge exists, blast radius is short by 20%

[phudayyy]

Summary

graphify affected under-reports blast radius when a dynamic import('…') sits inside a
function. The edge is present in graph.json — this is not the missing-edge bug from #2575,
which 0.9.38 fixed — but reverse traversal dead-ends on it, because a dynamic edge originates
from the enclosing symbol while a static edge originates from the file.

Measured on a real repo (~700 JS/TS files), affected --depth 3 returns 39 of 49 truly
affected files for one hub module and 24 of 30 for another: recall 0.80. Precision stays
1.00 — nothing is invented, files are simply unreachable. Raising --depth to 4, 5 or 6 does not
help, which is the signature of a dead end rather than a depth limit.

Root cause

Two lines in graphify/extractors/engine.py, both emitting relation: "imports_from":

# L1736 — static import
"source": file_nid,     # file → file

# L1289 — dynamic import, _dynamic_import_js()
"source": caller_nid,   # ENCLOSING SYMBOL → file

caller_nid is the file node only when the import() is at module level. Inside a function it is
that function's node, so the graph gets load() --imports_from--> target.ts and no file-level
edge dyn.ts → target.ts. Reverse traversal from target.ts therefore lands on load() and stops:
the only edge pointing at load() is dyn.ts --contains--> load(), and contains is not in
DEFAULT_AFFECTED_RELATIONS. Anything reachable only through that file is lost.

It escapes notice because it is invisible in the common case: if the next importer happens to import
that exact symbol by name, there is an edge into load() and traversal continues.

Minimal reproduction

Four files. mid.ts is byte-identical in both runs; only the position of the dynamic import
changes.

// src/target.ts
export const value = 1;

// src/dyn.ts   ← the only file that differs between the two runs
export async function load() {          // variant A: inside a function
  const m = await import('./target');
  return m.value;
}
// variant B: export const p = import('./target');   // module level

// src/mid.ts
import './dyn';
export const run = () => 1;

// src/top.ts
import { run } from './mid';
export const go = () => run();

$ graphify update . && graphify affected src/target.ts --depth 3

import('./target') is…	top.ts in the result
at module level	✅ yes
inside a function	❌ no

A second, independent axis reproduces it with the import fixed inside a function and only mid.ts
changing — traversal survives only when the importer names the enclosing symbol:

mid.ts imports…	top.ts reached
import { load } from './dyn' (the enclosing symbol)	✅ yes
import { other } from './dyn' (a different symbol)	❌ no
import * as ns from './dyn'	❌ no
import './dyn' (side-effect)	❌ no

Environment: graphify 0.9.38 (PyPI), macOS 15 / arm64, Python 3.13, TypeScript sources.

Suggested fix

Emit the dynamic edge at file granularity as well, so blast radius matches static imports:

# in _dynamic_import_js(), alongside the caller_nid edge
edges.append({**edge, "source": file_nid})

Keeping the symbol-level edge preserves the precision that makes graphify explain useful — the
call site is still recorded — while the file-level edge restores traversal. The deferred: True
flag added for #1241 should be kept on both so find_import_cycles still ignores them and no
phantom file cycle reappears.

Adding contains to DEFAULT_AFFECTED_RELATIONS would also reconnect it, but far more bluntly:
it would let every traversal climb from any symbol to its whole file, which would cost precision
everywhere to fix one relation.

Happy to send a PR with the fix plus a test extending tests/test_js_dynamic_imports.py — the
existing test asserts the edge exists, so an assertion that affected actually traverses it
would have caught this.

[phudayyy]

Correction to my own report, after bisecting far enough to patch it — the diagnosis above
was close but not right, and the line numbers were read off the stale main branch rather
than v8 (which is the default branch and what 0.9.38 ships). Sorry for the noise.

The rescue pass already emits the edge that fixes this. A dedupe suppresses it.

_rescue_js_dynamic_imports emits the file-level dynamic_import edge, and skips when the
AST pass already captured that import. The skip is keyed on the target alone:

for e in result.get("edges", []):
    if e.get("deferred") and e.get("relation") == "imports_from":
        deferred_ids.add(e.get("target"))

_dynamic_import_js anchors its edge on caller_nid, which is the file node only at
module scope — inside a function it is that function's node. So for an in-function
import() the dedupe sees "a deferred edge to this target exists", concludes the rescue
would restate it, and skips. The two edges are not the same statement: one says this
function defers that module, the other says this file depends on that module, and only
the second is at a granularity affected walks. The result is no file-level edge at all,
and the reverse walk stops at the enclosing function — the one edge pointing at it is
contains, deliberately not in DEFAULT_AFFECTED_RELATIONS.

So the dedupe was right, just keyed wrong. Matching on (this file's node, target) keeps
the genuinely redundant case — module-scope import(), where caller_nid is the file
node — collapsing to one edge, and lets the in-function case through.

The two-axis repro in the original report still stands and still reproduces; only the
explanation changes. My earlier suggestion (emit a second edge from _dynamic_import_js)
also works but is worse: it duplicates what the rescue is already there to do, and it makes
the file-level edge an imports_from, which find_import_cycles reads.

Branch: https://github.com/phudayyy/graphify/tree/fix/affected-traverses-dynamic-import

• one-line key change in _rescue_js_dynamic_imports, plus a per-file dedupe of the
  rescue's own emissions (two import('./x') in one file already produced two identical
  edges on v8 — rare while only module-scope reached the rescue, common once every
  in-function one does)
• 7 new tests, of which 5 fail on unmodified v8; the other 2 are controls that must keep
  passing (call-site precision preserved, module scope not double-counted)
• test_ast_captured_dynamic_import_is_one_fact_not_two asserted the invariant that is the
  bug, so it is rewritten rather than deleted, and the half that was always correct is
  pinned separately
• full suite 3929 passed / 13 failed — the same 13 that fail on a clean v8 checkout here
  (terraform, ollama, manifest, install_references), untouched by this change

Verified end to end on the same ~700-file TypeScript repo, ground truth built independently
of graphify:

target	before	after
types.ts d3	84/84 — 1.00	84/84 — 1.00
localDb.ts d3	39/49 — 0.80	49/49 — 1.00
contextCompaction.ts d3	24/30 — 0.80	30/30 — 1.00

Precision stays 1.00 throughout; the rebuilt graph gained 30 dynamic_import edges and
one imports_from. Happy to open the PR if the approach looks right to you.

[safishamsi]

Fixed in v0.9.39 (graphifyy==0.9.39 on PyPI). The 0.9.38 dynamic-import dedupe keyed only on the target, so an in-function import(...) (whose symbol-level edge is anchored on the enclosing function) suppressed the file-level edge affected traverses. The dedupe now keys on the importing file, emitting one file-level dynamic_import edge per file/target while keeping the call-site edge, so affected reaches the importer for side-effect / namespace / different-symbol imports. Thanks @phudayyy for the fix (PR #2588).