Repository navigation
Description
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
- Indexing completes but DB is empty (all zeros) — macOS arm64 v0.6.0 #260 — Indexing completes but DB is empty (all zeros) — macOS arm64 v0.6.0 — awaiting v0.7.0 retest (WAL checkpoint-on-open/close + startup recovery shipped via fix(store): checkpoint WAL on close and startup to prevent orphan accumulation #387/a6ad401; not deterministically reproducible)
- Silent index degradation — status:"indexed" but only ~500 nodes for 72k LOC Rust codebase #333 — ~500 nodes for 72k LOC Rust — reclassified: Rust extraction-depth gap, not corruption. Rust is tree-sitter-only (not in the hybrid-LSP set), so extraction is shallow; asked reporter for v0.7.0 node count + missing symbol kinds + a public repo to tighten the tree-sitter query.
- Silent index corruption after rapid kill/restart cycles #334 — Silent index corruption after rapid kill/restart cycles — awaiting v0.7.0 retest (fix(store): checkpoint WAL on close and startup to prevent orphan accumulation #387 checkpoints WAL on open+close; crash-safety covered by
bulk_crash_recovery/store_checkpointtests)
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
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.- A plausibility threshold gates the success status — open (enhancement).
- Recovery path is automatic — WAL is now checkpointed on open+close; no manual MCP reconnect needed.
- Concurrent-writer / rapid-kill scenarios reproducible in a test —
bulk_crash_recoverycovers 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)
- cbm v0.8.1 silently deletes project DBs on "corrupt" detection — data loss with no recovery #557 — project DBs deleted after corrupt detection; data loss / recovery behavior
Added 2026-07-09 (triage)
- Project remains listed but becomes unqueryable after MCP restart with stale WAL/SHM sidecars #790 — project remains listed but unqueryable after MCP restart with stale WAL/SHM sidecars
- index_repository with relative repo_path (".") corrupts and auto-deletes the project DB every run #794 — index_repository with relative repo_path (".") corrupts and auto-deletes the project DB every run
- Fast artifact export raw-copies a live WAL-mode DB — torn graph.db.zst that import then installs unchecked #895 — fast artifact export raw-copies a live WAL-mode DB → torn graph.db.zst installed unchecked
- Row-scan loops swallow SQLITE_CORRUPT — queries return plausible truncated/empty results with no error #896 — row-scan loops swallow SQLITE_CORRUPT → plausible truncated/empty results with no error
- Sequential pipeline emits invalid JSON: unterminated "broker" on ASYNC_CALLS edges, raw non-JSON Route properties #898 — sequential pipeline emits invalid JSON (unterminated "broker" on ASYNC_CALLS, raw non-JSON Route properties)
(#897 — stale -wal/-shm replay over fresh DB — has an active fix PR #940 and is tracked there.)
Activity
nwn900 commentedon Jun 19, 2026
I have the following issue too
putchi commentedon Jul 12, 2026
Filed #1037 — a healthy, already-indexed project db was silently quarantined to
.corruptand replaced with a near-empty graph, withstatus: "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_graphupdatingfile_hashes) are silent writers, so every concurrent session's reads widen the concurrent-writer surface.deploy/deployment(s)— not overridable via.cbmignore#1184DeusData commentedon Sep 5, 2026
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.
DeusData commentedon Oct 25, 2026
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.