[danusha2345]

Fixes #2913.

What happened

codegraph status opened the database read-write, so DatabaseConnection.open ran the writer's open-time repairs on it: migrations, the FTS-trigger and secondary-index recovery an interrupted bulk load leaves behind, WAL maintenance. While a codegraph index was running, that recovery recreated the five edge indexes the indexer had dropped for its bulk load (beginBulkEdgeLoad). The indexer's next insertEdges transaction had already read its endpoint ids, so the schema change invalidated its snapshot and the write failed with SQLite extended code 517, SQLITE_BUSY_SNAPSHOT: "Failed to index: database is locked". The issue's reproduction, a writer in a bulk edge load that runs the real codegraph status between its endpoint read and its edge insert, shows exactly that; with { readOnly: true } at the same point the writer succeeds.

The change

• Status opens read-only (CodeGraph.open(projectPath, { readOnly: true })). A read-only open skips migrations, bulk-load repair and WAL maintenance, as the MCP reader connections already do (Shared-daemon sessions lose CodeGraph with "writer lock held": stop() waits on an unregistered connection, and a blocked fallback refuses instead of reading (1.6.0) #1963), and everything status reads is a read.
• Status says when a rebuild is running. When another live process holds rebuild.pid, --json carries rebuildInProgress: true and the text output warns that the numbers are a snapshot of a graph being rebuilt. The check is the one assertNoRebuild already made, exported as isRebuildInProgress for a caller that reports rather than refuses; a lock left by a dead process is not a rebuild.

Crash repair is unchanged: a read-write open, the writer's own, still recreates what an interrupted bulk load dropped.

Tests

__tests__/status-during-rebuild.test.ts (4 tests), against the built CLI as the issue's reproduction:

• a writer holds a bulk edge load with rebuild.pid and writer.pid naming a live process; codegraph status --json answers with the statistics and rebuildInProgress: true, the dropped indexes are still dropped afterwards, and the writer's edge insert succeeds; endBulkEdgeLoad brings the indexes back;
• a read-write open on the same state recreates them (the writer-side recovery is unchanged);
• the text output names the running rebuild, and a lock with a dead pid is reported as no rebuild;
• a project with no rebuild reports as before.

The first test fails on main at the index check (status recreated the five indexes).

Full suite on main 69af19a with the native kernel (CODEGRAPH_KERNEL_EXPECT=1): 9,072 passed, 39 skipped, 0 failed; tsc --noEmit clean.

🤖 Generated with Claude Code

[colbymchenry]

Thanks @danusha2345! This landed in #2930 with you as the commit author: codegraph status now opens the index read-only and says when a rebuild is running. We added three things on top. An index built by 1.4.0 or older has no per-reference status column, so a read-only status failed there with "no such column: status"; it now reads such an index as it is. While a rebuild runs, status now skips the at-rest advice ("run sync", "re-index", the interrupted-run and WAL warnings) that contradicted your new warning. And the WAL warning now points at codegraph sync, since status no longer reclaims the log. We also added the issue's exact interleaving as a test. It ships in the next release.