Summary
The SQLite core bundled in libsql-ffi predates the upstream fix for the WAL-reset race — the ~16-year-old bug where a write transaction racing a checkpoint during WAL reset confuses the checkpointer about which pages were copied, so committed writes are silently lost or the database corrupts. Upstream SQLite fixed it in 3.51.3.
Versions checked (by reading the shipped sqlite3.h in the crates, 2026-08-12):
libsql-ffi 0.9.30 → bundled SQLITE_VERSION "3.45.1" — pre-fixlibsql-ffi 0.10.0-pre.4 → bundled 3.47.0 — still pre-fix
As far as I can tell there is no libsql release carrying the fix.
Why this matters to libsql users specifically
The triggering topology is a separate process checkpointing while other connections write — exactly the shape of running Litestream (or any external checkpointer) against a WAL database. That is a common libsql/sqlite deployment pattern. It is a tight-timing race, but Tailscale hit it repeatedly in production over six months, and Antithesis reproduced it deterministically in ~15 minutes.
Sources:
Ask
Rebase the bundled core to ≥ 3.51.3, or backport the checkpoint-path fix to the currently bundled versions. Happy to provide our reproduction/verification harness methodology if useful: N writer processes through the client, an external process issuing wal_checkpoint(TRUNCATE/RESTART) aggressively, asserting every committed key remains readable plus integrity_check per round. (For what it's worth: on 3.45.1 we did not reproduce the race in bounded runs — expected for a tight-timing bug, and not evidence of safety; the upstream fix plus that harness passing on 3.51.3 is what we ended up trusting.)
Summary
The SQLite core bundled in
libsql-ffipredates the upstream fix for the WAL-reset race — the ~16-year-old bug where a write transaction racing a checkpoint during WAL reset confuses the checkpointer about which pages were copied, so committed writes are silently lost or the database corrupts. Upstream SQLite fixed it in 3.51.3.Versions checked (by reading the shipped
sqlite3.hin the crates, 2026-08-12):libsql-ffi0.9.30 → bundledSQLITE_VERSION "3.45.1"— pre-fixlibsql-ffi0.10.0-pre.4 → bundled 3.47.0 — still pre-fixAs far as I can tell there is no libsql release carrying the fix.
Why this matters to libsql users specifically
The triggering topology is a separate process checkpointing while other connections write — exactly the shape of running Litestream (or any external checkpointer) against a WAL database. That is a common libsql/sqlite deployment pattern. It is a tight-timing race, but Tailscale hit it repeatedly in production over six months, and Antithesis reproduced it deterministically in ~15 minutes.
Sources:
Ask
Rebase the bundled core to ≥ 3.51.3, or backport the checkpoint-path fix to the currently bundled versions. Happy to provide our reproduction/verification harness methodology if useful: N writer processes through the client, an external process issuing
wal_checkpoint(TRUNCATE/RESTART)aggressively, asserting every committed key remains readable plusintegrity_checkper round. (For what it's worth: on 3.45.1 we did not reproduce the race in bounded runs — expected for a tight-timing bug, and not evidence of safety; the upstream fix plus that harness passing on 3.51.3 is what we ended up trusting.)