@rotorsoft/act-sqlite 1.22.7 → 2.0.0

package/README.md

@@ -111,6 +111,8 @@ The store owns a single libSQL connection, which is what makes the above true: w
 
 Raising `busy_timeout` is not the fix, and is worse than it looks. libSQL's busy wait blocks the Node event loop for its full duration: in a single process where both connections share that loop, the other connection's commit cannot run while the wait is in progress, so the wait is guaranteed to reach its timeout — having frozen your server, timers and all, the whole time. Measured, the failure moves from ~1 ms to the full timeout, and still fails.
 
+If a commit does lose that race, it fails with `StoreError` and stores nothing, and later commits can keep failing with `cannot commit transaction - SQL statements in progress`, for 20 seconds or more in a test, until the driver lets go of its failed statement. Restarting the process ends it at once.
+
 If a second component needs the same data, route it through the store (`query`, `query_streams`) rather than opening its own connection. If it genuinely must have raw SQL access, run it while the app is stopped.
 
 ### Database schema reference
@@ -139,8 +141,8 @@ Both adapters pass the same `runStoreTck` suite. Application code doesn't change
 
 ## Compatibility
 
-- **Node**: >=22.23.3
-- **Peer**: `@rotorsoft/act` >=0.39.0, `zod` ^4.4.3
+- **Node**: >=22.23.4
+- **Peer**: `@rotorsoft/act` of the same major, `zod` ^4.6.7
 - **Bundled deps**: `@libsql/client` ^0.17.3 (no native bindings)
 - **Module formats**: ESM + CJS
 - **Runtimes**: Node, Bun, Deno (libSQL pure-TS implementation); also runs in Turso-compatible edge environments