Problem
PRAGMA busy_timeout is a per-connection setting — it resets to 0 on every new SQLite connection. With 10+ concurrent processes (gateway, cron agents, subagents) hitting main.sqlite, a busy_timeout=0 means any concurrent write attempt instantly fails with SQLITE_BUSY instead of retrying.
Context
After an outage on Mar 7, 2026, the root cause was identified as:
journal_mode=delete (fixed to WAL — this is persistent)busy_timeout=0 (fixed to 5000 — but this is not persistent)
After gateway restart, busy_timeout reverted to 0, confirmed via:
sqlite3 ~/.openclaw/memory/main.sqlite "PRAGMA busy_timeout;"
# Returns: 0
Expected Behavior
The gateway (and any process opening main.sqlite) should set PRAGMA busy_timeout=5000 on every new connection open, not rely on a one-time manual PRAGMA.
Related
Environment
- OpenClaw gateway on macOS (arm64)
main.sqlite ~798MB- 10+ concurrent processes
Problem
PRAGMA busy_timeoutis a per-connection setting — it resets to 0 on every new SQLite connection. With 10+ concurrent processes (gateway, cron agents, subagents) hittingmain.sqlite, abusy_timeout=0means any concurrent write attempt instantly fails withSQLITE_BUSYinstead of retrying.Context
After an outage on Mar 7, 2026, the root cause was identified as:
journal_mode=delete(fixed to WAL — this is persistent)busy_timeout=0(fixed to 5000 — but this is not persistent)After gateway restart,
busy_timeoutreverted to 0, confirmed via:Expected Behavior
The gateway (and any process opening
main.sqlite) should setPRAGMA busy_timeout=5000on every new connection open, not rely on a one-time manual PRAGMA.Related
Environment
main.sqlite~798MB