Tracking down the 16-year-old WAL-reset SQLite bug

> We funded the open-source SQLite VFS shim that helped isolate the race condition almost immediately, and will help track down similar bugs in the future. Interesting example of a company funding open source - in this case paying for the development of a new and very specific debugging tool.

Well written post, really enjoyed reading it. > A single Go process exclusively accesses that database, and serves the control plane for those tailnets. This single-writer design is exactly how SQLite is meant to be used. This line led me to believe that the writer and checkpointing logic lived on the same database connection, so I was curious to find out how the data race occurred. However, the bug details on the SQLite page[0] outline that it can only ever occur if there are multiple connections open, so the writer and the checkpointer must have been on different threads. [0] https://sqlite.org/wal.html#the_wal_reset_bug

It says a lot about sqlite that a bug becomes front-page news on HN. I'm impressed that Tailscale took this seriously enough to engage with a commercial support contract. I'd love to work for a company that cared so much about correctness.

SQLite: 92 million lines of tests Dijkstra: Tests can only prove the presence of bugs, never their absence!

For this particular category of bug, SQLite's existing testing methodology is demonstrably outclassed by modern deterministic concurrency testing. https://antithesis.com/blog/2026/wal-reset-bug/