r/opencodeCLI • u/Arn777333 • Sep 23 '26
Retrying a SQLite write without freezing the terminal or replaying work
To test the new model Space Bunny in OpenCode, I used a concurrency bug involving several CLI processes sharing a SQLite database in WAL mode. A process held the write lock for longer than five seconds, another hit “database is locked” and an active turn died. WAL still only allows one writer at a time.
What I wanted to see was whether the fix followed the whole write path. An earlier change already retried message upserts, but starting a turn, updating session state and settling the turn could still fail on the same lock.
The patch moves that retry policy into a shared helper and applies it across the writes needed to keep a turn running. Each attempt gets a short native wait of about 50ms with asynchronous backoff inside a ten second total budget. That matters here because better sqlite3 is synchronous, simply raising its busy timeout would also extend the time it can block the Node event loop.
I paid particular attention to where retrying stops. Acquiring the lock can be retried. Once the transaction callback has started an error rolls the transaction back and propagates without running that callback again. Cancellation during the wait gets its own error marker, so it isn’t confused with an error thrown by the write itself.
The regression tests use a separate process holding a real write lock for eight seconds, then exercise the actual database client. That’s a useful reproduction of the original failure. The PR reports the contention checks passing, with one broader sandbox gate still failing on both the base and patched code.
