I wonder why it took so much time among entire team to actually look into the source code. That's probably third thing I would do after encountering that kind of issue. I would even look for a word "gigabyte" considering it is well documented, because bizarre things should be documented.

Curious if having the automated tests do db operations on a persistent db would catch this.

It would do inserts/deletes/updates/create_table/alter_column etc. randomly for a long time, continue even if an operation fails unless there is a crash. This way the db could grow without bound and queries can get very slow

This. This exact bloody attitude of people who claim "we want to write a compatible system" but can not be bothered to read — not even the source code — the freaking docs, freely available, is why we can't have any decently compatible with each other systems nowadays. There, look: [0], it's explicitly documented right on the SQLite's "Database File Format" page, and has been for a decade at least. How the fuck did you manage to write a clone of SQLite without reading the description of its file format? Like, seriously, how?

[0] https://sqlite.org/fileformat2.html#the_lock_byte_page

I don't even understand the point in rewriting something that is rock solid. And on top of that you guys are asking for full compatibility. This is just nonsense.

> To the point that we have a challenge [...]: if anyone can find a bug that leads to data corruption *and improve our simulator to catch it next time*, we will pay you a cash prize.

Uhh, you should be paying people if you get them to work for you.