Breaking the WAL

Antithesis, a company that uses AI agents to find software bugs, reproduced a 15-year-old SQLite Write-Ahead Logging (WAL) bug in 15 minutes using its tool, after SQLite released version 3.51.3 to fix the issue. The bug, which had existed since 2010, was discovered by SQLite after Tailscale experienced six months of uptime issues in 2025. Antithesis's founder, Carl, used Claude to instrument SQLite 3.51.2 and run a generic workload, catching the bug on the first run, and verified the fix in 3.51.3 with a clean run.

Hi, it’s Carl again. You may remember me as the guy who taught Claude to use Antithesis /blog/2026/agent skills/ . Earlier this year, SQLite released 3.51.3 https://sqlite.org/changes.html version 3 51 3 , which fixed a longstanding bug in their Write-Ahead Logging WAL https://www.sqlite.org/wal.html subsystem called the WAL-Reset bug https://www.sqlite.org/wal.html walresetbug . The bug had been hanging around since 2010, but the SQLite team had apparently been unaware of its existence until earlier this year more on this below . As they wrote at the time: “The bug is a data race with tight timing constraints. It is unlikely to occur in common use. The developers have never been able to reproduce the bug organically and had to add special testing logic to SQLite that deliberately triggers the circumstances of the bug in order to verify that the issue has been fixed.” I was actually on a road trip with my girlfriend when I read about this, but I’m also a giant database nerd, so I was immediately nerd-sniped, hard. Bugs in SQLite, after all, are legendarily rare. Moreover, this sounded like just a perfect brown M&M /docs/faq/poc faq/ what-s-with-the-brown-m-ms : a known, challenging bug that we could track down with Antithesis we’ve done this a lot in our POCs . On top of that, I’d recently shipped our skills for Claude. So, sitting on a hillside on the Sunshine Coast, I whipped out my phone, and asked Claude to get to work. I had it get SQL 3.51.2 – still buggy – set up in Antithesis, and then instrument the code with a bunch of Antithesis assertions. You can see fn-body-1 the instrumented version here https://github.com/antithesishq/sqlite/tree/3.51.2-instrumented . Shoutout here to my incomparably beautiful home province of British Columbia. Then I asked it to write a simple workload https://github.com/antithesishq/sqlite/blob/3.51.2-instrumented/antithesis/workload.c which exercised the WAL insert and checkpoint code. Notably, this is a completely generic workload. It just runs writes and checkpoints concurrently – things you’d expect to actually happen in production, all the time. The assertions are also generic to the bug, they’re all standard assertions you’d add to any database, things like “no lost committed writes” and “database is not corrupt” called integrity check in sqlite . fn-body-2 We actually find that often, the simplest workloads find the hardest bugs https://antithesis.com/bugbash/podcast/why-simple-workloads-find-the-hardest-bugs/ . On my first run, Antithesis caught the bug in 15 mins . Here’s the report https://orbitinghail.antithesis.com/report/aCR2n9FyaKKokD0FmJEwe WY/wJmubZgK vuqvk310T fb3xIUYPN g4Trx8Wk7ncyBM.html?auth=v2.public.eyJzY29wZSI6eyJSZXBvcnRTY29wZVYxIjp7ImFzc2V0Ijoid0ptdWJaZ0tfdnVxdmszMTBUX2ZiM3hJVVlQTl9nNFRyeDhXazduY3lCTS5odG1sIiwicmVwb3J0X2lkIjoiYUNSMm45RnlhS0tva0QwRm1KRXdlX1dZIn19LCJuYmYiOiIyMDI2LTA3LTAzVDIyOjAzOjU2LjU1OTAxOTA3NFoifc2jqEbpJ0ObboTZ2k6z37ZXTmsSlyH1YsQi4eotK5b-SOZNqhKcWpUPjJ8CaYTbLFOcOQammDaa3GUCSQXWtgs . The part you’re looking for is: Then I repeated the exercise with 3.51.3, with the same workload and Antithesis instrumentation https://github.com/antithesishq/sqlite/tree/3.51.3-instrumented . Sure enough, the run came back green. I thought about this today because Tailscale just wrote an excellent blog post https://tailscale.com/blog/sqlite-wal-reset-bug about resolving the uptime issues https://tailscale.com/blog/hypergrowth-isnt-always-easy they’d experienced in 2025. Those issues were how the SQLite team discovered the WAL-Reset bug. Tailscale suffered 6 months of shaky uptime, then they and the SQLite team spent weeks hunting the bug, rolled out and rolled back a fix that broke something else https://sqlite.org/changes.html version 3 52 0 , then had to wait two more months to see if the “real” fix 3.51.3 worked. To root cause the issue, they had to write a new transaction logging pipeline in Tailscale, then shim in a new debugging tool for the virtual filesystem layer in SQLite. In Antithesis, this process isn’t quite down to a single click, but one click will give you a causality analysis /docs/product/debugging/causality analysis/ that pinpoints the issue to within a fraction of a second, and deterministic, time-travel debugging /docs/product/debugging/simple mvd/ that allows you to do what-ifs and destructive analysis. As the Tailscale team wrote, “nobody wanted us to spend six months looking for bugs in SQLite. This was an immensely frustrating experience for both our customers and staff”. Finding bugs like the WAL-Reset bug is excruciatingly difficult perhaps even like crawling over broken glass – but with rare and difficult bugs, the real torture can come when you’re waiting to see if your fix actually worked. I’ve worked on enough databases, and have experienced this myself many, many times. So it was both sobering and uplifting to realize just how painful this bug had been in the wild. By giving agents the skills to use Antithesis, I’d just found and verified it in like an hour, from my phone, sitting under spruce trees in the sunshine. I knew our agent skills worked, but I had no idea they worked this well. If you have a gnarly database issue, call me.