fix(sqlite): handle turso StepResult::Sleep and bump to 0.8.0-pre.4

[chaliy]

Supersedes #2302.

What changed

Bumps turso_core (and turso_ext / turso_macros / turso_parser) 0.8.0-pre.3 -> 0.8.0-pre.4, and teaches the sqlite engine's step loop about the new StepResult::Sleep { duration } variant.

Sleep joins the IO | Yield arm: drive pending completions via io_step() and re-step. The duration is deliberately not honoured. Blocking would be wrong here — the engine is single-threaded and driven synchronously, so nothing else can produce the progress the sleep is waiting for, and std::thread::sleep is unavailable on the wasm targets this builtin also ships to. Upstream documents the fallback explicitly:

The statement asks the caller to wait for duration before stepping again, e.g. because a busy handler decided to retry after a delay. Callers that don't track time may treat this exactly like IO: drive the event loop and step again.

Spinning stays bounded by the existing wall-clock deadline (TM-SQL-005a) and by the ExecutionBudget work unit consumed on every loop iteration, so this cannot become an unbounded busy-wait.

The match over StepResult is kept exhaustive on purpose — that is exactly what surfaced this variant instead of letting it fall into a catch-all. Documented in knowledge/runtimes/sqlite-builtin.md.

Why

Without this, turso 0.8.0-pre.4 does not compile:

error[E0004]: non-exhaustive patterns: `StepResult::Sleep { .. }` not covered
   --> crates/bashkit/src/builtins/sqlite/engine.rs:196
error: could not compile `bashkit` (lib) due to 1 previous error

That is what takes down 21 jobs on #2302 — every Rust, Python, Node, WASM and coverage job fails on the same build error.

Before / After

Build and tests:

# before (turso 0.8.0-pre.4, unpatched — i.e. #2302)
error[E0004]: non-exhaustive patterns: `StepResult::Sleep { .. }` not covered
error: could not compile `bashkit` (lib) due to 1 previous error
error: could not compile `bashkit` (lib test) due to 1 previous error

# after
$ cargo build -p bashkit --features sqlite      # Finished, exit 0
$ cargo test  -p bashkit --features sqlite sqlite
test result: ok. 108 passed; 0 failed
test result: ok.  66 passed; 0 failed
$ cargo vet --locked      # Vetting Succeeded
$ cargo fmt --check       # clean

Performance — just bench-sqlite, same machine, pre.3 vs pre.4 across all 44 benchmarks:

benchmark	pre.3	pre.4	delta
sqlite_index/indexed_lookup_mem/10000	64163 µs	59069 µs	−7.9%
sqlite_query/aggregate_mem/10000	43728 µs	41015 µs	−6.2%
...
sqlite_parallel/vfs/16	22345 µs	25568 µs	+14.4%
sqlite_index/full_scan_mem/1000	4724 µs	5465 µs	+15.7%

median −1.6%, mean +0.1% (n=44, range −7.9% to +15.7%) — noise on a 4-CPU VM, no regression.

Note for reviewers: do not diff this against criterion-sqlite-vm-linux-x86_64-1777865268.md (May). That baseline reports ~780 µs for every row count including 10000, which is not comparable to the current bench shape and makes pre.4 look ~50x slower. The numbers above are a fresh same-machine A/B run of pre.3 against pre.4.

Risk

• Low
• The only behavioral surface is how the step loop paces itself when turso returns Sleep. If a future workload genuinely depends on backing off (a contended busy handler), this spins instead of sleeping until the deadline or budget trips — bounded, never unbounded, and it returns the existing query timed out error rather than hanging. Honouring the duration would require a wasm-safe sleep and a non-synchronous driver, neither of which exists today.
• Lockfile edit is scoped to the four turso crates; pre.4 changes only its internal version pins, so the unrelated windows-sys 0.52.0 / getrandom 0.3.4 re-unification that chore(deps): bump turso_core from 0.8.0-pre.3 to 0.8.0-pre.4 #2302 carries is avoided. Verified with cargo metadata --locked.

Checklist

• Tests added or updated — existing 174 sqlite tests cover the step loop on both backends. Sleep is not reachable from bashkit's synchronous single-connection backends (it comes from a busy-handler retry under contention), so there is no deterministic way to assert it from a test; the exhaustive match is the compile-time guard, and the rationale is recorded in knowledge.
• Backward compatibility considered — internal dependency bump, no public API change.

---

Generated by Claude Code

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	bashkit	09979d8	Commit Preview URL Branch Preview URL	Aug 16 2026, 10:08 AM