fix: disambiguate colliding node IDs from same-name files

[V0v1kkk]

Fixes #438

Summary

Adds a post-extraction pass that detects and resolves node ID collisions caused by files sharing the same stem (e.g. Program.cs in multiple directories).

_make_id(stem, name) uses only the filename stem, so src/App1/Program.cs and src/App2/Program.cs both produce program_program. This causes their methods and type nodes to silently merge into a single node.

The fix detects these collisions by grouping nodes by ID and checking if they come from different source_file paths. When a collision is found, all affected nodes are renamed by prepending the parent directory name (e.g. app1_program_program and app2_program_program).

Impact

Common in .NET solutions where each project has its own Program.cs, Startup.cs, AssemblyInfo.cs, etc. Also affects any multi-module project with naming conventions that produce duplicate file stems.

Test Plan

• Verified on a .NET solution with 2 Program.cs files
• Nodes correctly separated after fix
• Edges re-pointed to new node IDs
• Existing tests pass

[GustavoStingelin]

I'm not familiar with the codebase, so I asked a generic Copilot agent to review it:

Findings (ordered by severity):

Critical: cross-file edge targets can remain stale after renaming
In the rename pass, edge remapping is keyed only by the edge source_file, then applied to both source and target IDs ([extract.py:3225].
But cross-file uses edges are created with source_file set to the importing file while target points to a node in another file ([extract.py:2651].
Result: when a target node from file B is renamed, an edge originating in file A may not update its target, leaving dangling/mismatched IDs.

High: unresolved-call edges may reference old caller IDs
Raw calls store caller_nid before the collision-disambiguation step ([extract.py:1071], [extract.py:1072].
Colliding nodes are later renamed ([extract.py:3203].
During cross-file raw call resolution, the caller is read directly from raw_calls with no remap ([extract.py:3258], [extract.py:3262]).
Result: inferred calls can be emitted from non-existent source IDs after rename.

High: replacement ID can still collide and silently drop nodes
New IDs are built from only the parent directory name + old ID ([extract.py:3200], [extract.py:3201].
If two colliding files have the same parent directory name in different paths (for example, src/app/Program.cs and tests/app/Program.cs), both compute the same replacement ID, and one is dropped by seen_final_ids ([extract.py:3202], [extract.py:3206].
This reintroduces merge/loss behavior in a common monorepo layout.

The main issue is that this does not take into account the full path after the current working directory when generating the ID.

It would also be useful to add unit tests to cover these cases.

[V0v1kkk]

Thanks for the thorough review @GustavoStingelin! All three issues were real bugs. I've pushed a fix:

1. Cross-file edge targets remaining stale — Edge remap was scoped by source_file, so a target node in another file wouldn't be updated. Fixed by using a global old_id → new_id map that checks all files for the old target ID.

2. raw_calls caller_nid not remapped — Now remaps caller_nid in raw_calls before cross-file resolution runs, so inferred edges use the correct post-rename IDs.

3. Parent dir collision — Now uses progressively deeper path components until a unique ID is found. So src/app/Program.cs → src_app_program_program and tests/app/Program.cs → tests_app_program_program.

Also added 5 unit tests with fixture files covering all three scenarios:

• Same-stem files get unique IDs
• No duplicate IDs after disambiguation
• All edge sources reference valid nodes
• Same parent dir uses deeper path components
• Cross-file edges are properly remapped

[Qodo-Free-For-OSS]

Hi, The disambiguation pass checks candidate IDs only against IDs already assigned in this pass, not against all pre-existing node IDs, so it can generate a new ID that matches an existing node ID that hasn’t been processed yet. When that later node group is processed, it can be skipped entirely because its original ID is already in seen_final_ids.

Severity: action required | Category: correctness

How to fix: Reserve all existing IDs upfront

Agent prompt to fix - you can give this to your LLM of choice:

Issue description

Collision renaming picks new IDs without checking against the full set of existing node IDs, only against IDs already assigned during this pass. This can create a new ID that collides with an existing (not-yet-processed) node ID, causing the later node(s) to be skipped.

Issue Context

The collision loop iterates id_to_files.items(); the order depends on insertion order of IDs as nodes were appended. Because seen_final_ids is built incrementally, it is not safe for global uniqueness decisions.

Fix Focus Areas

• graphify/extract.py[3348-3387]

Suggested fix

1. Compute a reserved ID set before any renaming:
   • reserved_ids = {n['id'] for n in all_nodes}
2. When selecting candidate, require candidate not in (reserved_ids - {nid}) and not in seen_final_ids.
3. If you rename a node, update reserved_ids accordingly (remove old, add new) so subsequent candidates remain safe.
4. Add a regression test that constructs a case where a would-be rename collides with a different pre-existing ID, and assert no nodes are dropped.

We noticed a couple of other issues in this PR as well - happy to share if helpful.

---

Spotted by Qodo code review - free for open-source projects.

[V0v1kkk]

Good catch @Qodo-Free-For-OSS — this was indeed a real bug. Fixed in 72e24a5:

• reserved_ids is now pre-populated with all existing node IDs before the rename loop starts
• Candidate selection checks against both reserved_ids and seen_final_ids
• When a node is renamed, the old ID is removed from reserved_ids and the new one is added

Added a regression test (test_rename_does_not_collide_with_preexisting_id) with fixture files where the naive rename would produce a duplicate ID, and the test verifies no nodes are dropped.

Would love to see the other issues you mentioned — please share!