Realtime watcher self-triggers on .qdrant_code_embeddings (infinite loop)

[mike-lsadigital]

Bug Description

The realtime watcher (realtime_updater.py) enters an infinite loop when Qdrant embeddings storage is inside the watched repository tree. The watcher detects .qdrant_code_embeddings/storage.sqlite as a code change, triggering a full recalculation (~7 min), which writes new embeddings, which triggers another detection — ad infinitum.

Environment

• macOS (Apple Silicon) with Docker
• PollingObserver for Docker volume compatibility
• graph-code v0.0.38 (also confirmed on v0.0.40)

Evidence

From container logs after 7 days of uptime:

• grep -c "Change detected" logs → 860 detections
• grep -c "Recalculating all" logs → 859 full recalculations
• storage.sqlite detected as changed 20+ times on a single day

Root Cause

IGNORE_PATTERNS in constants.py does not include .qdrant_code_embeddings. The _is_relevant() filter in realtime_updater.py only checks against this frozenset, so Qdrant files pass through.

Note that .qdrant_code_embeddings is already in .gitignore, confirming it's recognized as generated output.

Proposed Fix

1. Add .qdrant_code_embeddings to IGNORE_PATTERNS in constants.py
2. Consider loading .cgrignore in the watcher (related: .cgrignore not pulled as a default check #277)

Happy to submit a PR if desired.

Related

• .cgrignore not pulled as a default check #277 — .cgrignore not pulled as a default check
• feat: add debouncing to realtime file watcher #213 — Debouncing PR (mitigates but doesn't fix root cause)
• Optimize realtime updater #86 — Optimize realtime updater

[xxxajk]

I'd love to see any of the files (./tmp/* during processing, .cgrignore, etc) all be able to be specified into a specified path, so it doesn't pollute a project with extra stuff. It makes any sort of tracking a nightmare. e.g. cgr --configdir=/some/other/place would be fantastic, and could contain a full config, with project path etc, v.s. what it does now.
I would do this myself, but I may find it difficult to find the time, and there are all sorts of problems I have to patch up before I can actually get to test anything, because I put in other debug points in the code to track progression, and other things. Debugging on the screen is also a really bad idea, and should go into a log file. So many things to fix at once, so little time.