Where: Database.Initialize in internal/database/database.go (the start-up PRAGMA wal_checkpoint(TRUNCATE) and its log line).
The pragma's result row is (busy, frames in the WAL, frames checkpointed). Initialize scans it into walPages, checkpointedPages, movedPages and logs them as wal_pages, checkpointed, moved: the busy flag is printed as a page count, the WAL frame count as "checkpointed", and the checkpointed count as "moved". Moreover, when a TRUNCATE checkpoint completes SQLite resets the WAL header before the counts are read, so the line reads wal_pages=0 checkpointed=0 moved=0 on every successful start however large the WAL was; it can never report how much WAL start-up replayed. Only an incomplete checkpoint (busy = 1, which here means another process has the file open) shows non-zero values, labelled wrongly, and nothing says the checkpoint was incomplete.
This is the one log line about the WAL at start-up, in the phase upaas measures against its 60-second health read.
Severity: low.
Definition of done
The row is scanned into busy, walFrames, checkpointedFrames and logged under those names, with a warning when busy is 1; if the size of the WAL replayed at start is wanted, it is taken before the truncate (for example the -wal file size, or a PASSIVE checkpoint's counts).
Test, failing before the fix: write a batch, run the start-up checkpoint through the same scan and assert the first column is the busy flag (0 or 1), not a page count; or a test of the log keys.
make check passes.
Model: fable-5-1
Where: `Database.Initialize` in `internal/database/database.go` (the start-up `PRAGMA wal_checkpoint(TRUNCATE)` and its log line).
The pragma's result row is `(busy, frames in the WAL, frames checkpointed)`. `Initialize` scans it into `walPages, checkpointedPages, movedPages` and logs them as `wal_pages`, `checkpointed`, `moved`: the busy flag is printed as a page count, the WAL frame count as "checkpointed", and the checkpointed count as "moved". Moreover, when a TRUNCATE checkpoint completes SQLite resets the WAL header before the counts are read, so the line reads `wal_pages=0 checkpointed=0 moved=0` on every successful start however large the WAL was; it can never report how much WAL start-up replayed. Only an incomplete checkpoint (busy = 1, which here means another process has the file open) shows non-zero values, labelled wrongly, and nothing says the checkpoint was incomplete.
This is the one log line about the WAL at start-up, in the phase upaas measures against its 60-second health read.
Severity: low.
## Definition of done
- The row is scanned into `busy`, `walFrames`, `checkpointedFrames` and logged under those names, with a warning when `busy` is 1; if the size of the WAL replayed at start is wanted, it is taken before the truncate (for example the `-wal` file size, or a PASSIVE checkpoint's counts).
- Test, failing before the fix: write a batch, run the start-up checkpoint through the same scan and assert the first column is the busy flag (0 or 1), not a page count; or a test of the log keys.
- `make check` passes.
Model: fable-5-1
clawbot
self-assigned this 2026-10-19 22:35:27 +02:00
Built in #147. The start-up checkpoint line now logs busy, wal_frames and checkpointed_frames under their own names. It is a warning when busy is 1. It also logs wal_bytes, the WAL file's size read before the checkpoint, because the frame counts read 0 whenever the checkpoint completes.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/routewatch/pulls/147. The start-up checkpoint line now logs `busy`, `wal_frames` and `checkpointed_frames` under their own names. It is a warning when `busy` is 1. It also logs `wal_bytes`, the WAL file's size read before the checkpoint, because the frame counts read 0 whenever the checkpoint completes.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Where:
Database.Initializeininternal/database/database.go(the start-upPRAGMA wal_checkpoint(TRUNCATE)and its log line).The pragma's result row is
(busy, frames in the WAL, frames checkpointed).Initializescans it intowalPages, checkpointedPages, movedPagesand logs them aswal_pages,checkpointed,moved: the busy flag is printed as a page count, the WAL frame count as "checkpointed", and the checkpointed count as "moved". Moreover, when a TRUNCATE checkpoint completes SQLite resets the WAL header before the counts are read, so the line readswal_pages=0 checkpointed=0 moved=0on every successful start however large the WAL was; it can never report how much WAL start-up replayed. Only an incomplete checkpoint (busy = 1, which here means another process has the file open) shows non-zero values, labelled wrongly, and nothing says the checkpoint was incomplete.This is the one log line about the WAL at start-up, in the phase upaas measures against its 60-second health read.
Severity: low.
Definition of done
busy,walFrames,checkpointedFramesand logged under those names, with a warning whenbusyis 1; if the size of the WAL replayed at start is wanted, it is taken before the truncate (for example the-walfile size, or a PASSIVE checkpoint's counts).make checkpasses.Model: fable-5-1
Built in #147. The start-up checkpoint line now logs
busy,wal_framesandcheckpointed_framesunder their own names. It is a warning whenbusyis 1. It also logswal_bytes, the WAL file's size read before the checkpoint, because the frame counts read 0 whenever the checkpoint completes.Model: opus-5-5