Found by the worker on #30: a database the app creates from next has auto_vacuum off, although Initialize (internal/database/database.go) runs PRAGMA auto_vacuum=INCREMENTAL. SQLite only lets that setting change before the database file is first written; the connection opens in WAL mode first, so the pragma comes too late and is ignored, and the periodic PRAGMA incremental_vacuum does nothing. Freed pages are never returned, so the file never shrinks after withdrawals.
Definition of done
A database the app creates fresh has auto_vacuum set to incremental, and the periodic incremental vacuum returns free pages.
An existing database with auto_vacuum off is handled on purpose: either left as it is and the fact logged once at startup, or converted, with the choice and its cost (a full VACUUM rewrites the file) stated on this issue before implementation.
A test covers the fresh-database case; make check stays green (in the Docker build).
Model: opus-5-5
Found by the worker on https://git.eeqj.de/sneak/routewatch/issues/30: a database the app creates from `next` has `auto_vacuum` off, although `Initialize` (`internal/database/database.go`) runs `PRAGMA auto_vacuum=INCREMENTAL`. SQLite only lets that setting change before the database file is first written; the connection opens in WAL mode first, so the pragma comes too late and is ignored, and the periodic `PRAGMA incremental_vacuum` does nothing. Freed pages are never returned, so the file never shrinks after withdrawals.
## Definition of done
- A database the app creates fresh has `auto_vacuum` set to incremental, and the periodic incremental vacuum returns free pages.
- An existing database with `auto_vacuum` off is handled on purpose: either left as it is and the fact logged once at startup, or converted, with the choice and its cost (a full `VACUUM` rewrites the file) stated on this issue before implementation.
- A test covers the fresh-database case; `make check` stays green (in the Docker build).
Model: opus-5-5
clawbot
self-assigned this 2026-09-29 11:23:36 +02:00
Fresh databases: add _auto_vacuum=incremental to the connection string in internal/database/database.go, next to the other per-connection settings. The driver applies it on open, before _journal_mode=WAL, so it takes effect on a new file before anything is written. The PRAGMA auto_vacuum=INCREMENTAL line in Initialize, which comes too late, goes.
Existing databases, the choice the definition of done asks for: leave them as they are and log once at startup that auto_vacuum is off, so the periodic incremental vacuum frees nothing on that file. Converting would take a full VACUUM, which rewrites the whole file, needs as much free disk again, and blocks writes for minutes on a multi-GiB database; that is not worth doing automatically for a table that refills from the live feed. A database created on a new, empty volume gets the fixed setting.
Test: a database the app creates in a test reports auto_vacuum incremental; after rows are deleted, Vacuum reduces the free page count.
Model: opus-5-5
Plan.
- Fresh databases: add `_auto_vacuum=incremental` to the connection string in `internal/database/database.go`, next to the other per-connection settings. The driver applies it on open, before `_journal_mode=WAL`, so it takes effect on a new file before anything is written. The `PRAGMA auto_vacuum=INCREMENTAL` line in `Initialize`, which comes too late, goes.
- Existing databases, the choice the definition of done asks for: leave them as they are and log once at startup that `auto_vacuum` is off, so the periodic incremental vacuum frees nothing on that file. Converting would take a full `VACUUM`, which rewrites the whole file, needs as much free disk again, and blocks writes for minutes on a multi-GiB database; that is not worth doing automatically for a table that refills from the live feed. A database created on a new, empty volume gets the fixed setting.
- Test: a database the app creates in a test reports `auto_vacuum` incremental; after rows are deleted, `Vacuum` reduces the free page count.
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.
Found by the worker on #30: a database the app creates from
nexthasauto_vacuumoff, althoughInitialize(internal/database/database.go) runsPRAGMA auto_vacuum=INCREMENTAL. SQLite only lets that setting change before the database file is first written; the connection opens in WAL mode first, so the pragma comes too late and is ignored, and the periodicPRAGMA incremental_vacuumdoes nothing. Freed pages are never returned, so the file never shrinks after withdrawals.Definition of done
auto_vacuumset to incremental, and the periodic incremental vacuum returns free pages.auto_vacuumoff is handled on purpose: either left as it is and the fact logged once at startup, or converted, with the choice and its cost (a fullVACUUMrewrites the file) stated on this issue before implementation.make checkstays green (in the Docker build).Model: opus-5-5
Plan.
_auto_vacuum=incrementalto the connection string ininternal/database/database.go, next to the other per-connection settings. The driver applies it on open, before_journal_mode=WAL, so it takes effect on a new file before anything is written. ThePRAGMA auto_vacuum=INCREMENTALline inInitialize, which comes too late, goes.auto_vacuumis off, so the periodic incremental vacuum frees nothing on that file. Converting would take a fullVACUUM, which rewrites the whole file, needs as much free disk again, and blocks writes for minutes on a multi-GiB database; that is not worth doing automatically for a table that refills from the live feed. A database created on a new, empty volume gets the fixed setting.auto_vacuumincremental; after rows are deleted,Vacuumreduces the free page count.Model: opus-5-5