Repository navigation
Decide: turn CGIS_AUTO_REFRESH on by default #540
Description
Split out of #175.
#538 added an opt-in refresh: with CGIS_AUTO_REFRESH=1, every graph-reading MCP tool runs an incremental ingest first when the graph is STALE. It shipped off by default, because it makes read tools write the database and can add a full rebuild's latency to a query.
What to decide after a release of real use
- Flip the default to on (and keep
CGIS_AUTO_REFRESH=0as the way out), or keep it opt-in. - Whether a refreshed answer should carry a one-line note in the tool output. Today the refresh is logged only to stderr, and the output shape doesn't change.
Evidence to gather first
- How often a refresh turns into a full rebuild, and its latency on large repos (owner-api; the FastAPI backend at 10k nodes / 38k edges). The rebuild cost is what the per-file cache issue opened alongside this one would cut.
- Any "database is locked" or failed-refresh lines in MCP logs.
Activity
zaebee commentedon Oct 2, 2026
An input for the decision: colbymchenry/codegraph (MIT) defaults to always-on auto-sync, but it also has a cheaper per-answer safety net we could adopt whatever this issue decides.
⚠️banner naming it and telling the agent to Read it directly. Pending files the answer doesn't touch go in a small footer instead.src/mcp/answer-freshness.ts): when auto-sync is degraded, it re-hashes (sha256) every file that fed the answer, with a budget of 200 files / 8 MB / 250 ms. If any file changed, or couldn't be checked within budget, it refuses with "cannot answer from this index" rather than answering confidently and wrongly.Our
freshness()is repo-wide. A per-answer check that hashes only the answer's files againstfiles_stateis cheap. It would make "off by default" much safer, or it could be the default while full refresh stays opt-in.Notes:
research/competitor-codegraph.md(idea 6).Generated by Claude Code