mirror of
https://github.com/jhd3197/ServerKit.git
synced 2026-11-09 05:24:49 +09:00
Juan DenisandClaude Opus 5
46fdf5fc13
`jobs` has had retention since day one, but the three tables that grow alongside it never did. `queue_messages` and `system_events` gain a row per scheduler tick and `api_usage_logs` one per request; measured on a single-app box that is ~25k rows/day, or ~11 MB/day of database forever. That is what filled a 25 GB host from nothing but routine updates: the database reached 809 MB in two months, and every update copies it twice as its safety net (a pre-upgrade snapshot plus a tree backup containing it), so each update cost ~1.6 GB. Adds builtin.telemetry_retention on a 6h tick, keeping `telemetry.retention_days` (default 30); 0 disables it. It reuses the prune from disk_reclaim_service, so the same guards apply -- terminal rows only, and a queue message still referenced by a surviving job is kept. It deliberately does NOT vacuum. VACUUM needs an exclusive lock and free space equal to the whole database, which is never acceptable on a background tick. Steady-state pruning leaves the freed pages on SQLite's freelist for reuse, so the file stops growing; `serverkit disk` remains what actually shrinks it after a backlog. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>