export obsidian: KeyError in to_obsidian when a community member id has no backing node in G

[antongulin]

Summary

graphify export obsidian aborts with KeyError in to_obsidian when a community's member list contains an id that has no backing node in G. The exporter assumes every clustered community member is a key in G.nodes (and in node_filename), but at least one synthesized member id ('agents_doc' in my run) is not — so the whole vault export crashes instead of skipping the dangling member.

Environment

• graphify(y) 0.8.36
• networkx 3.6.1
• Python 3.13.13
• backend: claude-cli (semantic), macOS

Repro

On a repo whose graph clusters into many communities (mine: ~10k nodes, 1206 communities after cluster-only), where multiple documents normalize to the same stem (e.g. several *-AGENTS.md / doc files across different directories):

graphify extract . --backend claude-cli
graphify cluster-only "$(pwd)" --backend=claude-cli   # succeeds: "Done - 1206 communities. GRAPH_REPORT.md and graph.json updated."
graphify export obsidian --dir "$VAULT"               # crashes

Traceback

Traceback (most recent call last):
  File ".../bin/graphify", line 10, in <module>
    sys.exit(main())
  File ".../graphify/__main__.py", line 3712, in main
    n = _to_obsidian(G, communities, str(obsidian_dir),
                     community_labels=labels or None, cohesion=cohesion or None)
  File ".../graphify/export.py", line 1010, in to_obsidian
    for node_id in sorted(members, key=lambda n: G.nodes[n].get("label", n)):
  File ".../graphify/export.py", line 1010, in <lambda>
    for node_id in sorted(members, key=lambda n: G.nodes[n].get("label", n)):
  File ".../networkx/classes/reportviews.py", line 196, in __getitem__
    return self._nodes[n]
KeyError: 'agents_doc'

Root cause

In to_obsidian (export.py:1010), the ## Members section iterates a community's members and dereferences each via G.nodes[n] (in the sort key) and node_filename[node_id] on the next line:

for node_id in sorted(members, key=lambda n: G.nodes[n].get("label", n)):
    data = G.nodes[node_id]
    node_label = node_filename[node_id]
    ...

members can contain an id that is not a node in G. Evidence from my run: the offending id "agents_doc" occurs 0 times in graphify-out/graph.json but does appear in graphify-out/.graphify_analysis.json (the sidecar the exporter draws community/label data from). The graph does contain real nodes whose ids end in _agents_doc (e.g. t3x_rte_ckeditor_image_classes_agents_doc and other *-AGENTS.md doc nodes from different directories), so this looks like a normalized/collapsed concept id that ends up in community membership without being materialized as a node in G. Either way, the export layer trusts a 1:1 member → G.nodes mapping that does not hold.

Suggested fix

Make the member iteration defensive so one dangling id can't abort the entire vault export:

members = [m for m in members if m in G.nodes and m in node_filename]
for node_id in sorted(members, key=lambda n: G.nodes[n].get("label", n)):
    ...

(optionally log.debug the skipped ids). The deeper fix would be upstream — ensure clustering/label assignment only emits real node ids as community members — but guarding the exporter prevents a single synthesized member from taking down the whole export obsidian run.

Workaround

Excluding the directory whose docs produced the colliding stem (via .graphifyignore) and re-running extract removes the synthesized member and lets the export complete.

[safishamsi]

Fixed in HEAD (commit a37672f). to_obsidian and to_canvas now filter community member IDs against the graph before the loop — dangling members are skipped rather than crashing with KeyError. Smoke tested on a fresh v8 install: export completes cleanly with dangling members present. Shipping in the next release.

[swells808]

Still reproduces in 0.9.5 — the #1236 fix only landed in to_obsidian, not to_canvas.

On a real export (graphify export obsidian, py3.14), to_obsidian writes all notes fine — the guard at export.py:1104 works:

members = [m for m in all_members if m in G and m in node_filename]

…but to_canvas then dies on the same dangling member:

File ".../graphify/export.py", line 1354, in to_canvas
    sorted_members = sorted(members, key=lambda n: G.nodes[n].get("label", n))
KeyError: 'cost_ladder_burner_outpost'

export.py:1354 in the shipped 0.9.5 is unguarded:

sorted_members = sorted(members, key=lambda n: G.nodes[n].get("label", n))

Same one-line filter as to_obsidian fixes it:

sorted_members = sorted(
    [m for m in members if m in G and m in node_filenames],
    key=lambda n: G.nodes[n].get("label", n),
)

(The node_filenames.get(node_id, safe_name(G.nodes[node_id]...)) fallback at line 1360 also derefs the dangling id in its default arg, so filtering members up-front covers both call sites.)

Net effect: notes export, then the run crashes before writing graph.canvas, leaving a partial mirror. Deterministic on any graph where community detection emits a member id absent from G. Could you reopen — the "fixed both to_obsidian and to_canvas" note didn't make it into the canvas path.

[safishamsi]

Good catch, @swells808 — you're right, the #1236 fix guarded to_obsidian but not to_canvas, so export obsidian still crashed writing graph.canvas. Fixed on v8 (2ba07e8): the same m in G and m in node_filenames filter now applies in to_canvas at both loops — the box-sizing loop (so the group box matches the cards actually drawn) and the card-layout loop (so the label sort and the node_filenames fallback never deref a dangling id). Verified: a community with a dangling member now exports graph.canvas cleanly with the dangling id skipped and real members present; to_obsidian unaffected. Regression test added. Ships next release.