Skip to content

Mode upgrade silently keeps weaker graph: incremental routing ignores stored index capability level #1273

Closed

Description

@astandrik

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

  1. Clone any small public repo, e.g. colinhacks/zod, to /tmp/zod.
  2. codebase-memory-mcp cli index_repository '{"repo_path":"/tmp/zod","mode":"fast"}' → completes with pipeline.route path=full; graph contains no full-mode-only edges.
  3. 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

  1. added this to the 0.9.1-rc milestone on Jul 28, 2026
  2. added
    parsing/qualityGraph extraction bugs, false positives, missing edges
    priority/highNeeds near-term maintainer attention; high-impact bug, regression, safety issue, or release blocker.
    on Jul 28, 2026
  3. DeusData commented on Jul 28, 2026

    @DeusData
    Owner

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingparsing/qualityGraph extraction bugs, false positives, missing edgespriority/highNeeds near-term maintainer attention; high-impact bug, regression, safety issue, or release blocker.

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions