tursodatabase / tursodatabase/libsql

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

Open
#2,271 0 comments 0 reactions 0 assignees View on GitHub

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-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:

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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.