In dit artikel bespreekt Carl Sverre de WAL-Reset bug, een complexe data race in het Write-Ahead Logging subsysteem van SQLite die sinds 2010 bestond maar pas onlangs in versie 3.51.3 is opgelost.
Sverre illustreert het verschil in debugging-efficiëntie door twee scenario's te vergelijken:
- De menselijke aanpak: Het team van Tailscale kampte zes maanden lang met instabiele uptime en moest handmatig nieuwe pipelines en tooling ontwikkelen om de bug uiteindelijk te pinpointen.
- De AI-aanpak: Met behulp van een AI-agent (Claude) en de tool Antithesis slaagde Sverre erin om binnen 15 minuten de bug te reproduceren via een generieke workload en specifieke assertions, terwijl hij op reis was.
De conclusie is dat het combineren van deterministische testing-tools met AI-agents de tijd voor het vinden en verifiëren van extreem zeldzame softwarebugs drastisch kan verkorten.
Het doorbreken van de WAL
Hoi, ik ben het weer, Carl. Je herinnert me misschien als de man die Claude heeft geleerd hoe hij Antithesis moet gebruiken.
Begin dit jaar bracht SQLite versie 3.51.3 uit, waarin een langdurige bug in hun Write-Ahead Logging (WAL) subsysteem werd opgelost: de zogenaamde WAL-Reset bug. De bug bestond al sinds 2010, maar het SQLite-team was blijkbaar niet op de hoogte van het bestaan ervan tot begin dit jaar. Zoals zij destijds schreven:
"De bug is een data race met zeer strikte timingbeperkingen. Het is onwaarschijnlijk dat deze voorkomt bij gewoon gebruik. De ontwikkelaars zijn er nooit organisch in geslaagd de bug te reproduceren en moesten speciale testlogica aan SQLite toevoegen die bewust de omstandigheden van de bug triggert om te kunnen verifiëren dat het probleem is opgelost."
Ik was op roadtrip met mijn vriendin toen ik hierover las, maar omdat ik een enorme database-nerd ben, werd ik direct gegrepen. Bugs in SQLite zijn immers legendarisch zeldzaam. Bovendien klonk dit als de perfecte testcase: een bekende, uitdagende bug die we met Antithesis zouden kunnen opsporen (iets wat we vaak hebben gedaan in onze Proof of Concepts). Daarnaast had ik onlangs onze skills voor Claude uitgebracht.
Dus, terwijl ik op een heuvel aan de Sunshine Coast zat, pakte ik mijn telefoon en vroeg ik Claude om aan het werk te gaan. Ik liet hem SQLite 3.51.2 — de versie waarin de bug nog aanwezig is — instellen in Antithesis en de code instrumenteren met een reeks Antithesis-assertions.
Vervolgens vroeg ik hem om een eenvoudige workload te schrijven die de WAL-insert en de checkpoint-code belastte. Belangrijk is dat dit een volledig generieke workload is; het voert simpelweg gelijktijdige schrijfacties (writes) en checkpoints uit, zaken die je in een productieomgeving constant zou verwachten. Ook de assertions zijn generiek voor de bug; het zijn standaard assertions die je aan elke database zou toevoegen, zoals:
- "Geen verloren gecommitteerde schrijfacties" (no lost committed writes)
- "De database is niet corrupt" (in SQLite genaamd integrity check)
We merken vaak dat de simpelste workloads juist de moeilijkste bugs vinden. Bij mijn eerste run vond Antithesis de bug binnen 15 minuten. In het rapport was het specifieke punt: Assertion failures triggered by the WAL-Reset bug.
Daarna herhaalde ik het experiment met versie 3.51.3, met dezelfde workload en Antithesis-instrumentatie. Zoals verwacht bleef deze run schoon.
Ik moest hier vandaag aan denken omdat Tailscale onlangs een uitstekend blogbericht schreef over het oplossen van de uptime-problemen die zij in 2025 ervoeren. Die problemen waren precies de reden waarom het SQLite-team de WAL-Reset bug ontdekte. Tailscale kampte zes maanden lang met een instabiele uptime. Daarna brachten zij en het SQLite-team weken door met het jagen op de bug, rolden ze een fix uit (die vervolgens iets anders brak) en moesten ze die daarna weer terugdraaien. Uiteindelijk moesten ze nog twee maanden wachten om te zien of de "echte" fix (3.51.3) daadwerkelijk werkte.
Om de grondoorzaak te achterhalen, moest Tailscale een nieuwe transaction logging pipeline schrijven en een nieuw debugging-tool implementeren voor de virtuele bestandssysteemlaag in SQLite. In Antithesis is dit proces niet direct terug te brengen tot één enkele klik, maar één klik geeft je wel een causaliteitsanalyse die het probleem pinpoint tot op een fractie van een seconde. Daarnaast biedt het deterministische time-travel debugging, waardoor je "wat-als"-scenario's en destructieve analyses kunt uitvoeren.
Zoals het team van Tailscale schreef: "Niemand wilde dat we zes maanden lang naar bugs in SQLite zouden zoeken. Dit was een immens frustrerende ervaring voor zowel onze klanten als ons personeel."
Het vinden van bugs zoals de WAL-Reset bug is extreem moeilijk (misschien zelfs te vergelijken met over glasscherven kruipen). Maar bij zeldzame en complexe bugs kan de echte marteling komen in het wachten op het bewijs dat je fix daadwerkelijk heeft gewerkt. Ik heb aan genoeg databases gewerkt om dit zelf vele malen te hebben ervaren.
Het was dan ook zowel ontnuchterend als bemoedigend om te beseffen hoe pijnlijk deze bug in de praktijk was geweest. Door agents de vaardigheden te geven om Antithesis te gebruiken, had ik de bug binnen een uur gevonden en geverifieerd, vanaf mijn telefoon, zittend onder sparrenbomen in de zon. Ik wist dat onze agent-skills werkten, maar ik had geen idee dat ze zó goed werkten.
Het doorbreken van de WAL
Hoi, ik ben het weer, Carl. Je herinnert me misschien als de man die Claude heeft geleerd hoe hij Antithesis moet gebruiken.
Begin dit jaar bracht SQLite versie 3.51.3 uit, waarin een langdurige bug in hun Write-Ahead Logging (WAL) subsysteem werd opgelost: de zogenaamde WAL-Reset bug. De bug bestond al sinds 2010, maar het SQLite-team was blijkbaar niet op de hoogte van het bestaan ervan tot begin dit jaar. Zoals zij destijds schreven:
"De bug is een data race met zeer strikte timingbeperkingen. Het is onwaarschijnlijk dat deze voorkomt bij gewoon gebruik. De ontwikkelaars zijn er nooit organisch in geslaagd de bug te reproduceren en moesten speciale testlogica aan SQLite toevoegen die bewust de omstandigheden van de bug triggert om te kunnen verifiëren dat het probleem is opgelost."
Ik was op roadtrip met mijn vriendin toen ik hierover las, maar omdat ik een enorme database-nerd ben, werd ik direct gegrepen. Bugs in SQLite zijn immers legendarisch zeldzaam. Bovendien klonk dit als de perfecte testcase: een bekende, uitdagende bug die we met Antithesis zouden kunnen opsporen (iets wat we vaak hebben gedaan in onze Proof of Concepts). Daarnaast had ik onlangs onze skills voor Claude uitgebracht.
Dus, terwijl ik op een heuvel aan de Sunshine Coast zat, pakte ik mijn telefoon en vroeg ik Claude om aan het werk te gaan. Ik liet hem SQLite 3.51.2 — de versie waarin de bug nog aanwezig is — instellen in Antithesis en de code instrumenteren met een reeks Antithesis-assertions.
Vervolgens vroeg ik hem om een eenvoudige workload te schrijven die de WAL-insert en de checkpoint-code belastte. Belangrijk is dat dit een volledig generieke workload is; het voert simpelweg gelijktijdige schrijfacties (writes) en checkpoints uit, zaken die je in een productieomgeving constant zou verwachten. Ook de assertions zijn generiek voor de bug; het zijn standaard assertions die je aan elke database zou toevoegen, zoals:
- "Geen verloren gecommitteerde schrijfacties" (no lost committed writes)
- "De database is niet corrupt" (in SQLite genaamd integrity check)
We merken vaak dat de simpelste workloads juist de moeilijkste bugs vinden. Bij mijn eerste run vond Antithesis de bug binnen 15 minuten. In het rapport was het specifieke punt: Assertion failures triggered by the WAL-Reset bug.
Daarna herhaalde ik het experiment met versie 3.51.3, met dezelfde workload en Antithesis-instrumentatie. Zoals verwacht bleef deze run schoon.
Ik moest hier vandaag aan denken omdat Tailscale onlangs een uitstekend blogbericht schreef over het oplossen van de uptime-problemen die zij in 2025 ervoeren. Die problemen waren precies de reden waarom het SQLite-team de WAL-Reset bug ontdekte. Tailscale kampte zes maanden lang met een instabiele uptime. Daarna brachten zij en het SQLite-team weken door met het jagen op de bug, rolden ze een fix uit (die vervolgens iets anders brak) en moesten ze die daarna weer terugdraaien. Uiteindelijk moesten ze nog twee maanden wachten om te zien of de "echte" fix (3.51.3) daadwerkelijk werkte.
Om de grondoorzaak te achterhalen, moest Tailscale een nieuwe transaction logging pipeline schrijven en een nieuw debugging-tool implementeren voor de virtuele bestandssysteemlaag in SQLite. In Antithesis is dit proces niet direct terug te brengen tot één enkele klik, maar één klik geeft je wel een causaliteitsanalyse die het probleem pinpoint tot op een fractie van een seconde. Daarnaast biedt het deterministische time-travel debugging, waardoor je "wat-als"-scenario's en destructieve analyses kunt uitvoeren.
Zoals het team van Tailscale schreef: "Niemand wilde dat we zes maanden lang naar bugs in SQLite zouden zoeken. Dit was een immens frustrerende ervaring voor zowel onze klanten als ons personeel."
Het vinden van bugs zoals de WAL-Reset bug is extreem moeilijk (misschien zelfs te vergelijken met over glasscherven kruipen). Maar bij zeldzame en complexe bugs kan de echte marteling komen in het wachten op het bewijs dat je fix daadwerkelijk heeft gewerkt. Ik heb aan genoeg databases gewerkt om dit zelf vele malen te hebben ervaren.
Het was dan ook zowel ontnuchterend als bemoedigend om te beseffen hoe pijnlijk deze bug in de praktijk was geweest. Door agents de vaardigheden te geven om Antithesis te gebruiken, had ik de bug binnen een uur gevonden en geverifieerd, vanaf mijn telefoon, zittend onder sparrenbomen in de zon. Ik wist dat onze agent-skills werkten, maar ik had geen idee dat ze zó goed werkten.
Groetjes,