kernel: open the database without writing node:sqlite's wal-index

Merged
BO
1mo ago
+117-1

A codegraph sync after checking out a commit 115 files away crashed with SIGBUS in 3 runs of 4. It died in the orphan sweep's first batch, right after folding a 413 MB WAL.

The kernel links its own SQLite build. POSIX locks never conflict within one process, so the kernel's read-only connection couldn't see node:sqlite's lock on the -shm file. It took itself for the first connection and truncated that file. node:sqlite still had the 26 regions that the large WAL had needed mapped, so its next write past the first 32 KB region touched a page beyond the end of the file.

Pool workers were already safe, because they read a .kr-snapshot copy. The main-thread kernel connection on the live file wasn't. Kernel connections now open with readonly_shm=1: the -shm is opened read-only, so the kernel can neither truncate nor rebuild it, and SQLite reads the WAL through its heap-memory wal-index instead. The URI path handles Windows drive letters and escapes the characters URIs reserve. If the URI form can't be opened, it falls back to the old open.

Checks:

  • New kernel-shm-coexistence.test.ts runs the crash scenario in a child process: it exits with a signal on the old kernel and 0 on this one. POSIX only, since the bug comes from POSIX lock semantics.
  • Sync after a 30-commit checkout: 5/5 clean at 13.2–14.0 s, the same speed as before. Its edges match the same sync with CODEGRAPH_KERNEL_RESOLVE=0 exactly (84,368 = 84,368).
  • cargo clippy --release -D warnings and check:kernel-rules are clean. The kernel parity, golden dump and resolution suites pass.
  • Full suite: 312 files, 5221 passed, 12 skipped.

Ledger: docs/design/metrics-ledger.md §5.56.