Bundled SQLite core predates the 3.51.3 WAL-reset fix (silent loss of committed writes under concurrent checkpointing)

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-fix
• libsql-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:

• SQLite fix (3.51.3): the added WAL-reset check in the checkpoint path
• Antithesis reproduction: https://antithesis.com/blog/2026/wal-reset-bug/
• Tailscale production postmortem: https://tailscale.com/blog/sqlite-wal-reset-bug

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.)