tursodatabase / tursodatabase/libsql
Bundled SQLite core predates the 3.51.3 WAL-reset fix (silent loss of committed writes under concurrent checkpointing)
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 17.2k
- Forks
- 531
- Avg merge
- 1h 12m
- Merged PRs (30d)
- 1
Description
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-ffi0.9.30 → bundledSQLITE_VERSION "3.45.1"— pre-fixlibsql-ffi0.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.)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating the bundled SQLite sources and shipped sqlite3.h in the libsql-ffi crates, then compare the bundled checkpoint path with SQLite 3.51.3's WAL-reset fix. Verify the update or backport with the described concurrent writers, external WAL checkpointing, committed-key assertions, and integrity_check rounds.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, rust, sqlite
- Domain
- databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100