v0.3.7
Fixed: no more SQLITE_BUSY crash on concurrent launches
If you launched dsx while another dsx process was already running (typically
a live TUI doing its background index refresh, or two launches racing), the
new process could die instantly with:
SQLiteError: database is locked (SQLITE_BUSY)
Two changes fix this:
- dsx now waits (up to 5s) for the other process's write to finish instead of
failing immediately. - Launching dsx no longer writes to the index at all when the schema is
already current, so plain concurrent launches can't contend at startup.
Your index data was never at risk — SQLITE_BUSY was pure lock contention,
and any interrupted operation rolls back cleanly under WAL.
Verification
- Reproduced the two-process contention both with and without the fix
(fails in 1ms before, succeeds after a short wait now). - Full test suite (62 tests), typecheck, and compiled-binary smoke test green
locally; all four release artifacts built by CI.
No new commands, flags, or behavior changes otherwise — upgrade in place.