mirror of
https://github.com/colbymchenry/codegraph.git
synced 2026-11-14 21:13:11 +08:00
danusha2345andClaude Opus 5.5
0187366697
Status opened the database read-write, so its open ran the writer's
repairs: migrations, the FTS-trigger and secondary-index recovery an
interrupted bulk load leaves behind, and WAL maintenance. During a
`codegraph index`, that recovery recreated the indexes the indexer had
dropped for its bulk load, and the indexer's next write, whose
transaction had already read, failed with SQLITE_BUSY_SNAPSHOT (517):
"Failed to index: database is locked".
Status now opens with `readOnly: true` and leaves every repair to the
writer, as the MCP reader connections already do. When another live
process holds `rebuild.pid`, it says so: a warning in the text output and
`rebuildInProgress` in `--json`, the only new key. `isRebuildInProgress`
is the check `assertNoRebuild` already made.
Added when landing it:
- A read-only open migrates nothing, so status on an index built by
1.4.0 or older (schema 7, no `unresolved_refs.status`) failed with "no
such column: status". The pending-reference count counts every row
when the column is missing, as the v8 migration marks them pending.
- While a rebuild runs, status skips the advice meant for an index at
rest: the interrupted-run references, "run sync", "re-index", and the
oversized-WAL warning, which mid-rebuild all describe the live run.
- Status no longer reclaims a killed session's oversized WAL, so the
warning names the next `codegraph sync` instead of status itself.
- Tests: the issue's exact interleaving (status inside the writer's edge
transaction, as in PR #2916's test), a pre-v8 index, and the
mid-rebuild advice.
Validation (Windows 11, Node 22.22):
- The issue's reproduction with our build of main 69af19ac: status inside
the transaction exits 0, the writer fails with errcode 517 and the five
dropped edge indexes come back. With this change the insert succeeds
and the indexes stay dropped.
- Real rebuilds of excalidraw 95307fa1 (716 files) with `codegraph
status` looping beside them, 3 with default settings and 3 with the
resolution window forced: main failed 6 of 6, each with "store worker:
database is locked" and an empty index; this change failed 0 of 6 over
46 status runs, with identical complete graphs (14,236 nodes, 61,210
edges).
- status-during-rebuild.test.ts: 7/7 pass. With main's sources 6 of 7
fail; without `readOnly` 3 fail, one with "database is locked"; with
the PR as written the pre-v8 and mid-rebuild cases fail.
- Indexes built by v1.6.2 (schema 11) and v1.4.0 (schema 7): the same
numbers as main, and the schema is left as it is. Interrupted-index
warnings (indexing, partial, failed) are unchanged.
Original PR #2921 by @danusha2345.
Fixes #2913
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>