Repository navigation
Watch mode on large repos schedules overlapping full refreshes and delays MCP visibility #792
Description
Problem
On a large Kùzu-backed repository under cgc watch, single-file edits can take a long time to become queryable through MCP because the watcher refresh path does too much full-repo work and can schedule overlapping refreshes for the same repo.
Reproduction context
Observed on a large monorepo of roughly:
- 2,190 files
- 8,764 functions
- 1,147 classes
Before
On that repo, a single watched source edit took about 20-26 seconds before the new symbol became queryable through MCP.
Instrumenting the refresh path also showed the relink phase scaling with the whole repo rather than the changed file set. In one run, the call relink was still at 100 / 1691 files after 103.7 seconds.
Expected
A watched single-file change should refresh incrementally:
- avoid overlapping refresh storms for the same repo
- avoid rebuilding imports for every file on each refresh
- avoid opening one DB session per changed file
- avoid relinking the entire repo when only a small file set changed
Candidate fix direction
- serialize refreshes per repo and batch queued file paths
- update imports incrementally for changed/deleted files
- batch changed-file graph updates into one DB session
- scope call/inheritance relinking to changed files plus affected callers/inheritors
Related work
PR #791 implements this approach and reduced the same large-repo single-file watch latency to <= 10 seconds for symbol visibility in local testing.
Activity
github-actions commentedon Apr 3, 2026
Hi! 👋 Join our CodeGraphContext Discord channel to collaborate: https://discord.gg/dR4QY32uYQ
DmytroTelish commentedon Apr 6, 2026
Hello @Shashankss1205,
I am writing to request an update to the attached PR. I am open to suggestions and criticism and would be happy to make any necessary edits.
I appreciate the work you have done but it is not suitable for large projects with frequent changes. I have therefore decided to take action. I can update the changes in my spare time if you can advise how I can assist.
Shashankss1205 commentedon Apr 9, 2026
Hey @DmytroTelish, i have recently refactored a major portion of the indexing logic. if you are willing to add incremental indexing support for cgc watch, you can join our discord and communicate your plans regarding this.
https://discord.gg/dR4QY32uYQ
k282 commentedon Apr 15, 2026
@DmytroTelish I have implemented incremental watch indexing for neo4j. You can do the similar approach for KuzuDB too. Here's what it does:
Incremental Update Algorithm (in watcher.py):
Watchdog-based — uses [watchdog] library to detect file system events (modify, create, delete)
Debounced — waits 2 seconds of quiet before processing (prevents IDE save storms)
Truly incremental — O(k) not O(n):
When a file changes, queries Neo4j for files that CALLS/INHERITS the changed file
Only re-parses the changed file + its callers/inheritors (the affected subset)
DETACH DELETEs stale edges, updates [imports_map] for just that file, re-links only the subset
Initial scan — on first [watch], does a full parse to build baseline; subsequent changes are incremental
k282 commentedon Apr 15, 2026
Refer this PR - #796
Shashankss1205 commentedon Jul 25, 2026
Resolved: watcher debounces per-path with scoped relink (
watcher.py:183-264, commit e4ed17c). Closing.