Bug: Concurrent workload still hangs on main (follow-up to #38)

[ElecTwix]

Hi Turso team — thanks for landing the fix referenced in #38. We pulled the latest main to verify, but unfortunately the concurrent workload still hangs on our end. We don’t have permission to reopen the closed issue, so we’re filing this follow-up.

Environment

• Commit: 97ac630 (contains the Turso driver ignores context deadline under concurrent load #38 fix)
• go version go1.25.1 X:nodwarf5 linux/amd64
• Fresh embedded lib built via ./build_lib.sh
• DSN: ./hang.db (local file; no TURSO_* env vars)

Steps to Reproduce

1. Pull the commit above and run ./build_lib.sh.
2. Check out our fork branch with a regression test mirroring the original workload: https://github.com/ElecTwix/turso-go/tree/concurrency-hang-test
3. Run:

   go test -run TestConcurrentWorkloadRespectsContextDeadline -v

   (The new test lives at concurrency_regression_test.go:1 on that branch.)

Observed Behavior

=== RUN   TestConcurrentWorkloadRespectsContextDeadline
    concurrency_regression_test.go:47: workload error: database error: database is locked
--- FAIL: TestConcurrentWorkloadRespectsContextDeadline (0.01s)
FAIL

The console still needs a 45 s watchdog to exit, so the workload never drains.

Diagnostics

• With RUST_LOG=turso_go=trace TURSO_LOG_FILE=hang_trace.log, we see repeated "Busy error during statement execution".
• Debug prints on the Go side show getTimeoutMs(ctx) returning ~30 000 ms for every Exec/Query, confirming the context deadline is being passed into stmtExec.
• Despite the timeout being set, the Rust layer returns Busy immediately under concurrent writes, so the threads stay blocked.

Expected Behavior
The workload should complete (or time out via context cancellation) rather than looping on Busy.

Artifacts

• Failing branch and test: https://github.com/ElecTwix/turso-go/tree/concurrency-hang-test
• Happy to attach the trace log if that helps.

Could you take another look? Let us know if there’s anything else we can collect.