Initialize now scans the row of the start-up PRAGMA wal_checkpoint(TRUNCATE) as busy, walFrames and checkpointedFrames. It logs them under busy, wal_frames and checkpointed_frames, and the line is a warning ("WAL checkpoint on startup incomplete") when busy is 1. The line also carries wal_bytes: the size of the WAL file the previous run left.
What the diff does not show:
When the TRUNCATE checkpoint completes, SQLite empties the WAL before it reads the counts. So on a normal start both frame counts are 0. wal_bytes is the figure that says how much WAL the previous run left.
New reads that size before it opens the database and passes it to Initialize, because opening the database writes a frame to the WAL.
There is no WAL file when the database is new, or after the last run closed the database (closing deletes it). That counts as 0 and logs no warning.
The incomplete-checkpoint test lasts about 5 seconds. The start-up checkpoint still waits out the connection's 5-second busy timeout before it gives up; this change leaves that wait as it is.
Disclosures:
Judgement call: the definition of done makes the WAL size optional. I added it, because without it the line reads 0 on every start that completes.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/routewatch/issues/117.
`Initialize` now scans the row of the start-up `PRAGMA wal_checkpoint(TRUNCATE)` as `busy`, `walFrames` and `checkpointedFrames`. It logs them under `busy`, `wal_frames` and `checkpointed_frames`, and the line is a warning ("WAL checkpoint on startup incomplete") when `busy` is 1. The line also carries `wal_bytes`: the size of the WAL file the previous run left.
What the diff does not show:
- When the TRUNCATE checkpoint completes, SQLite empties the WAL before it reads the counts. So on a normal start both frame counts are 0. `wal_bytes` is the figure that says how much WAL the previous run left.
- `New` reads that size before it opens the database and passes it to `Initialize`, because opening the database writes a frame to the WAL.
- There is no WAL file when the database is new, or after the last run closed the database (closing deletes it). That counts as 0 and logs no warning.
- The incomplete-checkpoint test lasts about 5 seconds. The start-up checkpoint still waits out the connection's 5-second busy timeout before it gives up; this change leaves that wait as it is.
Disclosures:
- Judgement call: the definition of done makes the WAL size optional. I added it, because without it the line reads 0 on every start that completes.
Model: opus-5-5
internal/database/database_internal_test.go, TestStartupCheckpointWarnsWhenIncomplete: the test finds the line by its message and never checks its level, though its comment says it checks that the checkpoint is logged as a warning. If the incomplete line is logged at info level instead, the test still passes, so the definition of done's "a warning when busy is 1" has no test. Acceptable: the test also asserts that the line's level is WARN, as TestStartupCheckpointLogsItsFigures already reads the level.
internal/database/database.go, Initialize: the comment above the WAL size read says there is no WAL file when the last run closed the database. But by the time Initialize reads the size, opening the database in New has already written one frame. So after every clean stop the line logs wal_bytes 4152 (the WAL header and one frame), not 0, and the branch for a missing file is taken only for a new database. Neither a reader of the code nor of the log can tell a clean stop from a run that left one frame. Acceptable: read the size in New before the database is opened, so the figure is exactly what the previous run left; or keep it where it is and make the comment say that the open has already written one frame, so a clean stop logs one frame's size.
Model: opus-5-5
1. `internal/database/database_internal_test.go`, `TestStartupCheckpointWarnsWhenIncomplete`: the test finds the line by its message and never checks its level, though its comment says it checks that the checkpoint is logged as a warning. If the incomplete line is logged at info level instead, the test still passes, so the definition of done's "a warning when `busy` is 1" has no test. Acceptable: the test also asserts that the line's level is `WARN`, as `TestStartupCheckpointLogsItsFigures` already reads the level.
2. `internal/database/database.go`, `Initialize`: the comment above the WAL size read says there is no WAL file when the last run closed the database. But by the time `Initialize` reads the size, opening the database in `New` has already written one frame. So after every clean stop the line logs `wal_bytes` 4152 (the WAL header and one frame), not 0, and the branch for a missing file is taken only for a new database. Neither a reader of the code nor of the log can tell a clean stop from a run that left one frame. Acceptable: read the size in `New` before the database is opened, so the figure is exactly what the previous run left; or keep it where it is and make the comment say that the open has already written one frame, so a clean stop logs one frame's size.
Model: opus-5-5
Initialize scanned the row of PRAGMA wal_checkpoint(TRUNCATE), which is
the busy flag, the frames in the WAL and the frames copied, into
wal_pages, checkpointed and moved; and a completed TRUNCATE reads 0 for
both counts. The line now logs busy, wal_frames and checkpointed_frames,
plus wal_bytes, the WAL file's size, which New reads before it opens the
database because the open writes a frame to the WAL. The line is a
warning when busy is 1. Tests open a database a second time while the
first stays open, with and without a read open on the first, and check
the line's level and figures.
Model: opus-5-5
TestStartupCheckpointWarnsWhenIncomplete now also asserts that the line's level is WARN.
Took the first option: New reads the WAL file's size before it opens the database and passes it to Initialize, so wal_bytes is exactly what the previous run left, and 0 after a clean stop. TestStartupCheckpointLogsItsFigures now asserts the logged size equals what the first database left, not just at least that, and the PR body no longer carries the deviation line about it.
Model: opus-5-5
1. `TestStartupCheckpointWarnsWhenIncomplete` now also asserts that the line's level is `WARN`.
2. Took the first option: `New` reads the WAL file's size before it opens the database and passes it to `Initialize`, so `wal_bytes` is exactly what the previous run left, and 0 after a clean stop. `TestStartupCheckpointLogsItsFigures` now asserts the logged size equals what the first database left, not just at least that, and the PR body no longer carries the deviation line about it.
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.
Closes #117.
Initializenow scans the row of the start-upPRAGMA wal_checkpoint(TRUNCATE)asbusy,walFramesandcheckpointedFrames. It logs them underbusy,wal_framesandcheckpointed_frames, and the line is a warning ("WAL checkpoint on startup incomplete") whenbusyis 1. The line also carrieswal_bytes: the size of the WAL file the previous run left.What the diff does not show:
wal_bytesis the figure that says how much WAL the previous run left.Newreads that size before it opens the database and passes it toInitialize, because opening the database writes a frame to the WAL.Disclosures:
Model: opus-5-5
internal/database/database_internal_test.go,TestStartupCheckpointWarnsWhenIncomplete: the test finds the line by its message and never checks its level, though its comment says it checks that the checkpoint is logged as a warning. If the incomplete line is logged at info level instead, the test still passes, so the definition of done's "a warning whenbusyis 1" has no test. Acceptable: the test also asserts that the line's level isWARN, asTestStartupCheckpointLogsItsFiguresalready reads the level.internal/database/database.go,Initialize: the comment above the WAL size read says there is no WAL file when the last run closed the database. But by the timeInitializereads the size, opening the database inNewhas already written one frame. So after every clean stop the line logswal_bytes4152 (the WAL header and one frame), not 0, and the branch for a missing file is taken only for a new database. Neither a reader of the code nor of the log can tell a clean stop from a run that left one frame. Acceptable: read the size inNewbefore the database is opened, so the figure is exactly what the previous run left; or keep it where it is and make the comment say that the open has already written one frame, so a clean stop logs one frame's size.Model: opus-5-5
cdc0d33da7to46c1c89568TestStartupCheckpointWarnsWhenIncompletenow also asserts that the line's level isWARN.Newreads the WAL file's size before it opens the database and passes it toInitialize, sowal_bytesis exactly what the previous run left, and 0 after a clean stop.TestStartupCheckpointLogsItsFiguresnow asserts the logged size equals what the first database left, not just at least that, and the PR body no longer carries the deviation line about it.Model: opus-5-5
Review passed.
Model: opus-5-5