Skip to content

fix(build): make semantic id-remap idempotent for dot-dir files (#1924) - #1926

Closed
SinghAman21 wants to merge 2 commits into
Graphify-Labs:v8from
SinghAman21:fix/1924-nonidempotent-node-id-prefix
Closed

fix(build): make semantic id-remap idempotent for dot-dir files (#1924)#1926
SinghAman21 wants to merge 2 commits into
Graphify-Labs:v8from
SinghAman21:fix/1924-nonidempotent-node-id-prefix

Conversation

@SinghAman21

Copy link
Copy Markdown
Contributor

Fix non-idempotent node IDs for files in dot-directories (#1924)

Running an incremental rebuild twice over an unchanged corpus should produce an identical graph. For files under a dot-directory it doesn't — .claude/CLAUDE.md's node ID gains one claude_ every run and never converges (claude_claude_graphify_trigger → claude_claude_claude_graphify_trigger → …). Logs show 0 re-extracted, so it's the preserved-node path, not extraction.

Cause: semantic_id_remap() rewrites legacy IDs to the canonical full-path stem. For a dot-dir file the canonical stem (claude_claude) contains the shorter legacy stem (claude) as a prefix. The guard only skipped old_stem == new_stem, so an already-canonical ID still matched the claude prefix, lost one segment, and got the full stem prepended back — +1 each run.

Fix: skip the remap when the ID is already canonical (== new_stem or starts with new_stem + "_"), the same guard graph_has_legacy_ids() already uses. Legitimate legacy migration still runs once.

Testing: added tests/test_semantic_id_remap_idempotent.py (stable across reruns, legacy forms still migrate once); build/merge/watch/id suites pass.

SinghAman21 and others added 2 commits July 15, 2026 21:26
…hify-Labs#1924)

A non-AST node whose source_file sits in a dot-directory (e.g.
.claude/CLAUDE.md) had its id re-prefixed with the parent segment on
every incremental rebuild, so graph.json never converged:

    claude_claude_graphify_trigger
    -> claude_claude_claude_graphify_trigger   (one claude_ per run)

The canonical full-path stem (claude_claude) contains the shorter
zero-parent legacy stem (claude) as a proper prefix. _semantic_id_remap
only skipped old_stem == new_stem, so an already-canonical id still
matched the shorter "claude" form, got one segment stripped, and had the
full stem re-prepended forever. Preserved nodes ride the build_merge path
through this remap on every update, so 0-re-extracted runs still mutated.

Add the already-canonical guard the read-only graph_has_legacy_ids()
detector already uses: skip when norm_nid == new_stem or starts with
new_stem + "_". Legacy migration (bare-stem and file-node forms) still
runs exactly once.
@safishamsi

Copy link
Copy Markdown
Collaborator

Thanks for this. The same dot-dir id-accretion bug (#1924) was already fixed on v8 by #1917 (19c496d): the idempotency guard in _semantic_id_remap skips an id that already carries its canonical stem, so a file like .claude/CLAUDE.md migrates once and then stays stable. Verified against the #1924 repro. Closing as already-resolved rather than merging a second fix for the same path — much appreciated regardless.

@safishamsi safishamsi closed this Jul 15, 2026
@SinghAman21

Copy link
Copy Markdown
Contributor Author

hey @safishamsi thanks for your explanation.
could you suggest me which issue i should work on next?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants