Breaking the WAL
51–59 of 59 posts
Re: Breaking the WAL
#52I understand the author feels he missed an opportunity to catch a bug in Sqlite - but this still feels like catching something in hindsight. Just knowing the bug the is in Sqlite's concurrency engine is a huge win. But reading over tailscale's blogpost, I'm not sure how I would connect the dots to "this issue I'm seeing in production" to "load this up in antithesis". It seemed half the battle was figuring out if the…
Re: Breaking the WAL
#53Hi! I'm the author and the person who was on a road trip when I decided to do this experiment back in July. I'm super excited to finally get the blog post out, and even better, alongside a post describing the root cause process that went into the project. You can read about Tailscale's story here: https://tailscale.com/blog/sqlite-wal-reset-bug I'm only sad that I didn't put SQLite under test earlier in the year, or…
Go find bugs that haven't been yet found, and then brag about them :joy:
Re: Breaking the WAL
#54Re: Breaking the WAL
#55Earlier quoted context omitted.
> This exercises the portion of the WAL code that, from a trivial read-through, is most likely to contain bugs (and turns out, did!). Suuure. So why exactly haven't you found this bug already a long time ago? I mean it is trivially obvious that this is where bugs in SQLite would be, right? SQLite is open source and is one of the most popular databases, surely testing it to find bugs would also be obvious?
We put many things to the test, but it costs money, and until very recently we haven't had a way to do this without a lot of human oversight. Now that we have https://github.com/antithesishq/antithesis-skills and LLMs are getting pretty reliably good at writing workloads, we are looking at ways to open up our technology to the OSS community. We have already started down that path with Etcd last year ( https://etcd.io…
Re: Breaking the WAL
#56as a long time lurker who usually enjoys antithesis posts, this was a pretty existentially sad read. we all know that company blog posts here always tend to be ads at their core, but historically afaicr antithesis generally toes the line well of keeping the "thing we sell is really good" as a side dish to the "i (author) did very interesting deep thinking and/or hard work to accomplish something cool" entree. this on…
Re: Breaking the WAL
#57as a long time lurker who usually enjoys antithesis posts, this was a pretty existentially sad read. we all know that company blog posts here always tend to be ads at their core, but historically afaicr antithesis generally toes the line well of keeping the "thing we sell is really good" as a side dish to the "i (author) did very interesting deep thinking and/or hard work to accomplish something cool" entree. this on…
I am okay with companies shilling their tools. Ultimately I'd want my employer to buy good tools that make our lives easier specifically wrt debugging which I genuinely hate. However this post could have been a better walk through about what Claude found, what was the exact root cause and how it can be fixed instead of the generic Anthithesis found it in 15m.
this is a pretty wide trend for blog content nowadays so im not suprised overall, i just commented because previous antithesis blogs were better than this to that criteria. just take a look at the other older write ups on their site compared to this one and you’ll see a very clear difference in depth and effort of content.
Re: Breaking the WAL
#58Hi! I'm the author and the person who was on a road trip when I decided to do this experiment back in July. I'm super excited to finally get the blog post out, and even better, alongside a post describing the root cause process that went into the project. You can read about Tailscale's story here: https://tailscale.com/blog/sqlite-wal-reset-bug I'm only sad that I didn't put SQLite under test earlier in the year, or…
Re: Breaking the WAL
#59Hi! I'm the author and the person who was on a road trip when I decided to do this experiment back in July. I'm super excited to finally get the blog post out, and even better, alongside a post describing the root cause process that went into the project. You can read about Tailscale's story here: https://tailscale.com/blog/sqlite-wal-reset-bug I'm only sad that I didn't put SQLite under test earlier in the year, or…
Unless you guys routinely add assertions to libraries I don't see how you would have caught this?
I mean for sure databases should guard against lost writes but how would you have known to add that particular assert?