Repository navigation
Description
Version
main @ 97ce23f (0.9.x line)
Platform
macOS (Apple Silicon) — the routing logic is platform-independent C, so all platforms are affected; verified on macOS.
Install channel
Built from source
Binary variant
standard
What happened, and what did you expect?
Indexing a repository with a weaker mode and then re-running with a stronger mode on an unchanged repo silently keeps the weaker graph. The incremental router compares stored file hashes and the discovered-file threshold, but never the capability level of the stored index, so a fast-built graph is treated as valid for moderate/full requests.
Expected: when the requested mode requires capabilities missing from the stored index (e.g. full builds SIMILAR_TO / SEMANTICALLY_RELATED edges that fast never produces), the run forces a full rebuild. Conversely, re-running with a weaker requested mode (as the failure hint on large repos suggests, cf. #563) should not tear down stronger capabilities already present in the graph.
Reproduction
- Clone any small public repo, e.g.
colinhacks/zod, to/tmp/zod. codebase-memory-mcp cli index_repository '{"repo_path":"/tmp/zod","mode":"fast"}'→ completes withpipeline.route path=full; graph contains no full-mode-only edges.- Re-run unchanged:
codebase-memory-mcp cli index_repository '{"repo_path":"/tmp/zod","mode":"moderate"}'.
Actual: the log shows the incremental no-op path; the graph never gains the capabilities moderate/full are supposed to add, and nothing signals that the stored index is weaker than requested.
Expected: the router detects the capability gap and forces a full rebuild.
Symmetric downgrade case: after a full index, re-run with "mode":"fast" on a repo with changed files. Before the fix this rebuilt from scratch at the weaker mode, permanently discarding the stronger capabilities; expected is a run that keeps the full graph and only narrows the requested view.
Logs
level=info msg=pipeline.route path=incremental
# ^ after fast → moderate on an unchanged repo; should have been a forced full rebuild
Project scale (if relevant)
Reproduces on repos of any size (observed in the wild on a ~124k-file repo, see #563).
- I searched existing issues and this is not a duplicate.
- My reproduction uses shareable code (a public OSS repository), not proprietary code.
Activity
DeusData commentedon Jul 28, 2026
Thanks for checking both upgrade and downgrade directions.
The current main route is still file-count based: try_incremental_or_delete_db compares discovered files with stored hash count and takes incremental when the threshold fits (src/pipeline/pipeline.c:1170-1182). The existing mode_change_reindex log at 1184-1187 is only the opposite file-count branch; it does not read stored index_mode capability metadata. So the log name does not invalidate this report.
PR #1263 is linked and queued for review. The issue remains a priority/high 0.9.1 correctness bug; triage is not pre-approving the implementation. Thank you for catching the misleading existing log label too.