MCP session serves a stale graph indefinitely after the background watcher re-indexes

[melihemreguler]

Summary

The background watcher correctly detects a change and re-indexes, and the database is updated within ~15 s. But the live MCP session that registered the watcher keeps serving the pre-change graph indefinitely. Only an index_repository call issued from that same session refreshes its view.

Effect: in a long-lived agent session the knowledge graph silently freezes at session start while the on-disk graph moves on.

Repro

1. Start the MCP server with cwd set to a git repo, so the session registers the project (auto_watch default true).
2. Send initialize, then tools/call index_repository.
3. Record search_graph(label=Function) — baseline.
4. Append a new function to a source file. Do not call index_repository.
5. Every 15 s, query search_graph over the live MCP session and run codebase-memory-mcp cli search_graph from a separate process.

Observed

+ 15s  MCP: stale     [func_alpha_renamed, func_epsilon, func_gamma, main]
       CLI: HAS ZETA  [func_alpha_renamed, func_epsilon, func_gamma, func_zeta, main]
...
+120s  MCP: stale     (unchanged for the full run)
       CLI: HAS ZETA  (correct since +15s)

Server stderr during the run confirms the watcher did its job:

level=info msg=watcher.changed project=… strategy=git
level=info msg=watcher.reindex project=… path=…

Then, in the same session:

tools/call index_repository  ->  search_graph immediately returns func_zeta

Diagnosis

The session's read view appears to be invalidated only by writes originating in that session. Writes committed by the daemon-owned watcher do not invalidate it.

Impact

This is a silent-staleness failure, the most damaging class for an agent-facing tool. Over a normal working day the agent answers "who calls X" from a morning snapshot with no indication the answer is stale, and the watcher's work is invisible to the very session that registered it.

Notes

• Explicit re-index correctness is fine. Adding, renaming and deleting functions and files, committed and uncommitted, was verified across 8 scenarios with no ghost nodes and no drift.
• Incremental re-index costs ~0.2 s on a 796-file repo, so calling index_repository after edits is a viable workaround.
• Secondary observation, possibly by design but undocumented: the watcher registers only the session's cwd project. A repo indexed explicitly via index_repository from a session whose cwd is elsewhere is never watched — the log shows watcher.watch for the cwd project instead.

---

Environment

• Version: codebase-memory-mcp 0.9.0 (release binary, darwin-arm64)
• OS: macOS 26.5.2, Apple Silicon
• Repo under test: DeusData/codebase-memory-mcp @ af3ffbd (21,143 nodes / 123,103 edges)
• Verified identically through both the MCP server and cli mode (outputs byte-identical)

[DeusData]

Thanks for the clean watcher/session split. The code supports the reported stale-view mechanism: resolve_store caches the SQLite connection for the current project and returns it unchanged on every subsequent query (src/mcp/mcp.c:1970-1984). A watcher publishing a new database generation does not invalidate that per-session handle, while an index_repository call in the same session naturally crosses the mutation path and refreshes state.

That is a silent correctness failure for long-lived sessions, so I have routed it to 0.9.1-rc at priority/high. The proof that a same-session reindex refreshes the view is particularly useful for binding the fix. Thank you.