Summary
When the writer fails and the codebase falls back to the read-only path, the previously-stamped PRAGMA user_version readiness bits remain set. A reader that opens the DB after the failed-but-stamped state believes the rows it is missing are present, leading to silent zero-result queries.
This is distinct from #1513 (non-atomic RMW of user_version) and #1518 (orphan reference rows after partial failure) — both about write-side atomicity. The gap here is read-side trust of stale ready bits after a writer fault.
Where
src/CodeIndex/Database/DbContext.cs:162-177 (read-only fallback path)src/CodeIndex/Database/DbWriter.cs:98-118 (ready-bit stamping)
Why it matters
A common failure mode: writer crashes mid-rewrite (OOM, kill -9), fold rows are partially populated but the bit is already set. The next reader sees fold_ready=true and returns "no impact found" for symbols that genuinely have impact, with no warning.
Suggested approach
(1) On read-only open, validate that the data backing each ready bit is internally consistent (e.g. row counts above zero for the family); on mismatch, force-clear the bit and log a degraded-readiness reason. (2) Add a --integrity-check mode that does this aggressively. (3) Have writers stamp inside the same transaction as the data changes (#1513 covers this), but also keep a "writer epoch" so readers can spot crashed writers.
Summary
When the writer fails and the codebase falls back to the read-only path, the previously-stamped
PRAGMA user_versionreadiness bits remain set. A reader that opens the DB after the failed-but-stamped state believes the rows it is missing are present, leading to silent zero-result queries.This is distinct from #1513 (non-atomic RMW of user_version) and #1518 (orphan reference rows after partial failure) — both about write-side atomicity. The gap here is read-side trust of stale ready bits after a writer fault.
Where
src/CodeIndex/Database/DbContext.cs:162-177(read-only fallback path)src/CodeIndex/Database/DbWriter.cs:98-118(ready-bit stamping)Why it matters
A common failure mode: writer crashes mid-rewrite (OOM, kill -9), fold rows are partially populated but the bit is already set. The next reader sees
fold_ready=trueand returns "no impact found" for symbols that genuinely have impact, with no warning.Suggested approach
(1) On read-only open, validate that the data backing each ready bit is internally consistent (e.g. row counts above zero for the family); on mismatch, force-clear the bit and log a degraded-readiness reason. (2) Add a
--integrity-checkmode that does this aggressively. (3) Have writers stamp inside the same transaction as the data changes (#1513 covers this), but also keep a "writer epoch" so readers can spot crashed writers.