mirror of
https://github.com/openclaw/openclaw.git
synced 2026-08-02 09:21:35 +00:00
d998a1db84
* fix: SQLite WAL file can stay inflated on a running gateway until restart Since #82366 switched the periodic 30-minute checkpoint to PASSIVE (to keep WAL maintenance off the event loop), no checkpoint on a running process truncates the WAL *file* any more -- only close() does, i.e. a restart. wal_autocheckpoint recycles WAL space in place but never shrinks the file, and is itself a PASSIVE checkpoint a reader can transiently block. So when a reader briefly pins frames (e.g. a memory reindex, a backup, a slow query), the WAL grows past the autocheckpoint size and then stays parked at that high-water mark for the whole life of the process. Observed in production: a 1.6 GB agent DB left a 1.6 GB -wal that only manual TRUNCATE checkpoints could reclaim. This affects every SQLite-backed store (task registry, plugin state, proxy capture, memory host, ...), not just memory. Set PRAGMA journal_size_limit (default 64 MiB, overridable via journalSizeLimitBytes) right after wal_autocheckpoint so any completing checkpoint -- including the PASSIVE periodic/auto ones #82366 now relies on -- truncates the WAL file back to the ceiling. This restores the bounded on-disk WAL that TRUNCATE used to give, without reintroducing the blocking checkpoint #82366 removed: journal_size_limit only changes how far a completing checkpoint truncates, never checkpoint timing. The 64 MiB ceiling sits ~16x above the autocheckpoint steady state (~4 MB at 1000 pages), so it is inert in normal operation and engages only on pathological growth. Related: #82366, #81715 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix: tighten SQLite WAL ceiling proof --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Co-authored-by: Peter Steinberger <steipete@gmail.com>
