Repository navigation
benchmark crashes: KeyError 'links' on networkx 3.x (graph.json uses 'edges' key) #1198
Description
Summary
graphify benchmark crashes with KeyError: 'links' against a graph produced by graphify extract --no-cluster.
Environment
graphifyy0.8.35 (installed viauv tool install graphifyy)networkx3.6.1- Windows, Python 3.13
Repro
graphify extract <code-dir> --out <out-dir> --no-cluster
cd <out-dir>
graphify benchmarkTraceback
File ".../graphify/benchmark.py", line 105, in run_benchmark
G = json_graph.node_link_graph(data, edges="links")
...
File ".../networkx/readwrite/json_graph/node_link.py", line 247, in node_link_graph
for d in data[edges]:
KeyError: 'links'
Root cause
The graph.json written by extract stores edges under the edges key, not links:
keys: ['nodes', 'edges', 'hyperedges', 'input_tokens', 'output_tokens']
But benchmark.py calls json_graph.node_link_graph(data, edges="links") with the literal old key. On networkx ≥3.x the hardcoded "links" no longer matches what extract emits, so data["links"] raises KeyError.
Suggested fix
Pass edges="edges" to match the extract output (or detect the present key):
G = json_graph.node_link_graph(data, edges="edges")Notes
- Reproduced on a
--no-clusterraw extraction; haven't checked clustered output, which may differ. - Otherwise the tool is great —
extracton a code-only corpus is fast and fully offline (a 47-file TS app → 247 nodes/470 edges in ~2.3s, zero API calls). Just wanted thebenchmarktoken-reduction numbers and hit this. Thanks!
Activity
atlas-architect commentedon Jun 8, 2026
Update: this bug is wider than
benchmark— the samenode_link_graph(data, edges="links")vs theedges-keyedgraph.jsonalso breaksaffected(and any command going through that load path). On networkx 3.6.1,graphify affected "<node>"fails with:Root cause: the writer emits
"edges"(build.py reads the JSON directly — see the comment atbuild.py:384), but the readers callnode_link_graph(..., edges="links")→KeyError: 'links', which the surroundingexcept TypeError:(the old-networkx missing-kwarg guard) doesn't catch.Same pattern at ~9 call-sites:
affected.py:152,benchmark.py:105,callflow_html.py:231,global_graph.py:37+:91,multigraph_compat.py:115,serve.py:33, and__main__.py(lines 2702 / 2840 / 2930 / 3405 / 3463 / 3653).Fix is one token at each site —
edges="links"→edges="edges"(match the writer's key). Verified locally on networkx 3.6.1: patchingaffected.py+benchmark.pymade both commands work correctly —affectedreturns the full reverse-dependency cone, andbenchmarkreports its token-reduction metric (2.6× on a real Next.js/TS repo).query/explain/pathalready work because they read the JSON directly rather than vianode_link_graph. Happy to send a PR if that's useful.safishamsi commentedon Jun 8, 2026
Not a bug — the claim has the keys inverted.
graph.jsonstores edges under"links"(written byexport.py:512vianode_link_data(G, edges="links")), andbenchmark.py:105correctly readsedges="links". Verified on networkx 3.6.1: all 16 benchmark tests pass. Applying the suggested fix (edges="edges") would introduce the crash, not fix it.