Was curious so we checked and yep, Antithesis finds this bug in about 15 minutes. Will post a repro/writeup here soon.
I'm equal parts intrigued and skeptical- I guess if the prompt doesn't lead on there is a bug there then I'm impressed.
Tracking down the 16-year-old WAL-reset SQLite bug
91–100 of 263 posts
Re: Tracking down the 16-year-old WAL-reset SQLite bug
#92Re: Tracking down the 16-year-old WAL-reset SQLite bug
#93Re: Tracking down the 16-year-old WAL-reset SQLite bug
#94Earlier quoted context omitted.
I've been a fan of Tailscale since encountering it for the first time at a previous job at a small startup. Someone asked if anyone had a Linux machine when we were all testing out something, and I mentioned I had a personal Linux desktop but wasn't sure how to connect it to the VPN for access, and it turned out that the solution was just literally running two commands in the terminal after installing tailscale from…
With a desktop its usually possible from the network setting GUI? Worked like that last time I needed to use a VPN for access to a corporate network.
Re: Tracking down the 16-year-old WAL-reset SQLite bug
#95Glad this got found and fixed, but I continue to be astounded at the amount of work people put into making SQLite do things that would be much simpler with other systems.
This is a little like “we shot ourselves in the foot and then performed surgery on our foot, and everything is resolved now.”
Re: Tracking down the 16-year-old WAL-reset SQLite bug
#96> Whenever corruption occurred, we had to stop the control plane process on the shard while we repaired or restored the database. This was painful for tailnets on that shard, because their entire control plane disappeared during that recovery window. Gotta love single points of failure...
Re: Tracking down the 16-year-old WAL-reset SQLite bug
#97Was curious so we checked and yep, Antithesis finds this bug in about 15 minutes. Will post a repro/writeup here soon.
Re: Tracking down the 16-year-old WAL-reset SQLite bug
#98Earlier quoted context omitted.
The shard was already a way to make it not a single point of failure.
This is a great example of outages looking different from the perspective of the operator vs the user. Because there's many shards the blast radius of failure is contained to a small subset of users but for those users it's an outage. The way it's designed you can't lose any shards without impacting users. Compare to say Elasticsearch where it's possible to lose nodes and lose shards without the user noticing. One ap…
Re: Tracking down the 16-year-old WAL-reset SQLite bug
#99SQLite: 92 million lines of tests Dijkstra: Tests can only prove the presence of bugs, never their absence!
I admit to curiosity as to whether static analysis could have caught this. E.g., Rust's type system (yeah yeah I know) catches all data races, unless they originate in unsafe code, which this one might or might not have; a hypothetical Rust SQLite would probably need a lot of unsafe ( https://github.com/tursodatabase/turso has 556 unsafe blocks in the core), and I don't have a sense of whether the particular part tha…
What do you know?
Re: Tracking down the 16-year-old WAL-reset SQLite bug
#100Earlier quoted context omitted.
I admit to curiosity as to whether static analysis could have caught this. E.g., Rust's type system (yeah yeah I know) catches all data races, unless they originate in unsafe code, which this one might or might not have; a hypothetical Rust SQLite would probably need a lot of unsafe ( https://github.com/tursodatabase/turso has 556 unsafe blocks in the core), and I don't have a sense of whether the particular part tha…
There was a post recently using TLA to model this issue and (re)discover the bug: https://news.ycombinator.com/item?id=48730953 .