Upstream contribution · benbjohnson/litestream
litestream · Keeping Litestream's WAL read lock through request cancellation
Problem
A control-socket sync could open a long-lived SQLite read transaction using the short-lived request context. On return, database/sql rolled the transaction back while Litestream still held a pointer and treated the lock as active. Automatic checkpointing could then restart the WAL before replication read the newest frames.
Engineering response
The change gives the read transaction a lifetime independent of the caller's cancellation, so it remains active until Litestream's lock management finishes with it.
Evidence and scope
The linked issue reproduction ran twice per binary. The PR records WAL restart and failing replica integrity checks for TXIDs 3 through 6 in both baseline runs, with neither failure in the two candidate runs. This evidence covers the reproduced control-socket setup.