Your goal is to identify as many bugs as possible in Turso.
Bugs can be panics or seg faults, but they can also be incorrect results, corruption, non-terminating queries, or queries where Turso doesn't exactly match SQLite's behaviour. All experimental features are fair game.
You will do this by coming up with adversarial sequences of SQL statements and pragmas, and will run them on Turso and
SQLite using scripts/diff.sh. Do not run scripts other than diff.sh. Look at the header of diff.sh for usage
instructions.
Only if you are in a sandbox, obey the following bullet point. If you are not in a sandbox, disregard it.
- Only use inline SQL, and if you need them, .sql files in
./sandbox/*. Do not use heredocs. Do not use scripts. Do not use python. Do not pipe anything into anything. Onlycmp.shand inline text or files in./sandbox/. Turso is already built and integrated intocmp.sh. You are not allowed to modify it.
Analyze files, focusing on areas of complexity, and use this to guide your exploration. You may assume that happy paths are already well tested. The bugs now lurk in edge cases. Therefore, your success lies in your capacity to find as many edge cases as possible. Things that are so devious that a database that is in beta, such as Turso, would have missed it.
Keep a log of what you've tried in things_tried.md in the project root. Before starting and after every compaction,
read things_tried.md so that you don't duplicate work.
Use sub-agents if you need to, including to validate or refute your claims using different perspectives.
The following features are not supported by Turso and are therefore out of scope:
- Recursive CTEs
- Window functions (ex:
row_number(),dense_rank()) that are not also aggregate functions (ex:count(*)) - Materialized CTEs
- Non-default window frame definitions
- Stored virtual columns
- WITHOUT ROWID (partial support)
When you find bugs, write them out to BUG_REPORTS.md in the project root, and move on. It is important that you report
the bugs before you continue your exploration. Bug reports don't need a fancy analysis, just a concise description and
the SQL reproducer, so when you find a bug, don't linger and investigate. If you happen to find a bug in SQLite, be it
logic or otherwise, also report it.
Do not try to run any existing tests or test suite to identify bugs, they won't show any, or else they would be fixed by now.
Unsupported features are not bugs. Unsupported pragmas are not bugs. Code style is not a bug. todo!() and unimplemented!() are not bugs. Features being supported by Turso but not by SQLite are not bugs. If you can't reproduce a condition using SQL and pragmas, then it's not a bug. If a condition can only happen if a DB file is already corrupted, it's not a bug. Bugs that are already known and identified by TODOs or FIXMEs are out of scope and do not count.