bug(indexer): Updating one file destroys globally-shared Module nodes and other files' edges #1392

Activity

1. Shashankss1205

   added

   bugSomething isn't workingSomething isn't working

   severity: highWrong graph content, data loss, or a broken workflow with no clear signalWrong graph content, data loss, or a broken workflow with no clear signal

   area: indexerParsing, discovery, resolution, persistenceParsing, discovery, resolution, persistence

   on Jul 26, 2026
2. github-project-automation

   added this to CodeGraphContext Roadmapon Jul 26, 2026
3. github-project-automation

   moved this to Backlog tasks in CGC Progress Boardon Jul 26, 2026
4. github-project-automation

   added this to CGC Progress Boardon Jul 26, 2026
5. github-actions commented on Jul 26, 2026

   

   github-actionsbot

   on Jul 26, 2026 – with GitHub Actions

   Contributor

   More actions

   Hi! 👋 Join our CodeGraphContext Discord channel to collaborate: https://discord.gg/dR4QY32uYQ
6. Shashankss1205 commented on Jul 26, 2026

   

   Shashankss1205

   on Jul 26, 2026

   CollaboratorAuthor

   More actions

   I tried to fix this and backed the fix out. Reporting what I found, because the issue is real but the suggested fix does not work.

   Confirmed, with a sharper reproduction

   The failure needs update_file_in_graph (what the watcher actually calls on an edit), not just delete_file_from_graph:

   repo: mod.rb defines `module Shared`; a.rb and b.rb both `include Shared`
   
   after index        : INCLUDES edges -> 2
   after edit mod.rb  : INCLUDES edges -> 0      ← never restored
   

   The Module node is recreated when mod.rb is re-added, but a.rb/b.rb are not reprocessed — they are neither CALLS callers nor INHERITS neighbours — so their INCLUDES edges are gone for good.

   Why the proposed fix does not work

   The report suggests filtering the cascade with WHERE element.path = $path. I implemented that and it changes nothing here, because the Ruby Module node does carry a path, equal to mod.rb:

   MATCH (f:File {path: $mod_rb})
   OPTIONAL MATCH (f)-[:CONTAINS]->(element)
   WHERE element.path = $mod_rb
   RETURN element.name, label(element)
   ->  helper  (Function)
   ->  Shared  (Module)      ← still matched, still deleted
   

   Also: the pathless case does not reproduce

   I tested the other half of the premise — a genuinely pathless shared Module — and it is not affected:

   a.py and b.py both `import os`   ->  Module 'os', 2 importers
   delete_file_from_graph(a.py)     ->  Module 'os' survives, 1 importer   ← correct
   

   That is because imported modules are reached by IMPORTS, not CONTAINS, and the cascade only follows CONTAINS. Both baseline main and the patched version behave identically here.

   What a real fix needs

   Exclude Module from the DETACH DELETE and drop only the CONTAINS relationship, so the node and its inbound INCLUDES/IMPORTS edges survive re-indexing of the defining file. The obstacle is that the label predicate is not portable — Kùzu uses label(n), Neo4j uses labels(n) — so it needs either a backend branch or a second query. The alternative is to re-link dependents after re-adding a file that defines shared symbols.

   I did not want to guess at that in a PR I could not verify on both backends. #1425 contains only the encoding fix; this one is untouched.
7. github-project-automation

   moved this from Backlog tasks to In progress in CGC Progress Boardon Jul 26, 2026
8. Shashankss1205

   closed this as completedin #1429on Jul 31, 2026
9. github-project-automation

   moved this from In progress to Done in CGC Progress Boardon Jul 31, 2026