Skip to content

task: Silent index corruption / incomplete index reported as success (3 issues) #391

Open
4 of 11 issues completed

Description

@DeusData

Scope

Umbrella tracker for cases where indexing reports status: "indexed" / ready but the resulting graph is catastrophically incomplete (single-digit % of expected node count, or empty). The reports cluster around macOS, large Rust projects, and rapid kill/restart cycles where the previous process didn't release WAL or hash-row state cleanly.

PR #387 ("checkpoint WAL on close and startup to prevent orphan accumulation") resolves the WAL subset; reporters asked to re-test on v0.7.0.

Sub-issues

Status (2026-05-31)

The shared WAL/checkpoint root cause (#260, #334) is addressed by #387 in v0.7.0 (checkpoint on open + close, startup WAL recovery), with existing crash-recovery regression tests. Neither is deterministically reproducible in CI (timing/platform-specific), so both await reporter confirmation on v0.7.0. #333 is a distinct Rust extraction-completeness gap (tree-sitter-only language), not corruption — tracked on that basis pending a reproducible Rust repo.

Acceptance

  1. status: "indexed" is never returned when the index is materially incomplete — WAL stranding fixed (fix(store): checkpoint WAL on close and startup to prevent orphan accumulation #387); a plausibility-threshold gate (criterion 2) remains a candidate enhancement.
  2. A plausibility threshold gates the success status — open (enhancement).
  3. Recovery path is automatic — WAL is now checkpointed on open+close; no manual MCP reconnect needed.
  4. Concurrent-writer / rapid-kill scenarios reproducible in a test — bulk_crash_recovery covers the committed/uncommitted invariants.

Why one task

All three reports share the surface symptom (success reported, graph materially incomplete); #260/#334 share a WAL-checkpointing root cause, while #333 turned out to be a separate Rust-extraction-depth gap.

Added 2026-06-29 (triage)

Added 2026-07-09 (triage)

(#897 — stale -wal/-shm replay over fresh DB — has an active fix PR #940 and is tracked there.)

Activity

  1. added
    bugSomething isn't working
    stability/performanceServer crashes, OOM, hangs, high CPU/memory
    taskUmbrella task grouping multiple related issues
    on May 30, 2026
  2. nwn900 commented on Jun 19, 2026

    @nwn900

    I have the following issue too

  3. added
    priority/highNeeds near-term maintainer attention; high-impact bug, regression, safety issue, or release blocker.
    on Jun 30, 2026
  4. added this to the 0.9.1-rc milestone on Jul 8, 2026
  5. putchi commented on Jul 12, 2026

    @putchi

    Filed #1037 — a healthy, already-indexed project db was silently quarantined to .corrupt and replaced with a near-empty graph, with status: "indexed" reported throughout. Correction after re-testing (details in #1037): my initial SQLite-version-mismatch theory was wrong — the current binary reads/writes the old-format file fine, and a controlled reindex under quiet conditions completed cleanly. The corrected profile is concurrent access: a burst of CLI calls (detect_changes / hook-augment / index_repository) while ~6 long-lived MCP stdio servers from parallel agent sessions held the same WAL db. Likely another datapoint for this umbrella rather than a new root cause. One observation possibly relevant umbrella-wide: query tools that incremental-sync (e.g. search_graph updating file_hashes) are silent writers, so every concurrent session's reads widen the concurrent-writer surface.

  6. DeusData commented on Sep 5, 2026

    @DeusData
    OwnerAuthor

    The residual sparse absolute-loss case landed on main in a1e1beb (#1851): a dump that persisted zero nodes against a positive committed baseline is now reported as degraded even below the sparse floor, while sparse partial dumps keep their ratio exemption. This does not close the umbrella; the remaining items here are untouched.

  7. DeusData commented on Oct 25, 2026

    @DeusData
    OwnerAuthor

    Thank you for the concurrent-access evidence and the correction to the SQLite-version hypothesis. The sparse-loss improvement noted above does not close the remaining corruption/completeness cases, including #1037. Those remain maintainer follow-up rather than a request to reproduce data loss again. Sorry for the delay—this is waiting on maintainer follow-up, and I’ll follow up soon.

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 workingpriority/highNeeds near-term maintainer attention; high-impact bug, regression, safety issue, or release blocker.stability/performanceServer crashes, OOM, hangs, high CPU/memorytaskUmbrella task grouping multiple related issues

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions