Current source and delivery status — 2026-09-15
Disposition: retained independent report; implementation is excluded from the current delivery. No production fix for this issue has been committed or merged. The experimental working-tree patch is isolated and is not part of #818. Its additional controls and mutations do not establish a dependency of configuration management or a cause of any historical CI latency failure.
SDK main 3194cf3c includes PR #776. Public native Durable/Async session construction selects the native WAL path. The ordinary SQLite fixture discussed below is a separate existing path. This report does not request replacing native storage, routing native operations through SQLite, changing Async acknowledgements or modifying any performance contract. The original report and its proposed acceptance are retained for traceability; they are not an instruction to expand the configuration work.
Original report, evidence and acceptance
A real SQLite commit invoked by SqliteConsensusLogStore::save_committed blocks unrelated Tokio tasks on a current-thread runtime. The synchronous run_admitted_sqlite_write helper correctly preserves borrowed caller scope, but only hands off the scheduler on multithread runtimes. The asynchronous storage entry point needs an owned, bounded dispatch path for current-thread execution.
A controlled synthetic test on 0105ef6837f5b3de399be33b97e4644586cdb4ac uses the existing fixed-store commit hook and original two-second cleanup fallback. All three multithread controls pass. The three otherwise identical current-thread cases fail: normal commit progress, cancellation while the transaction owns the connection, and rollback following commit rejection. The independent task cannot run until the hook's cleanup fallback returns. No timing allowance was changed. This reproduces a scheduling defect; it does not establish the cause of a separate hosted latency failure.
Acceptance:
- Keep synchronous borrowed/non-Send helper and startup/LocalSet behavior intact.
- Dispatch the owned committed-frontier write without blocking unrelated current-thread runtime tasks, with a process-wide bound covering queued and active work across store/runtime churn.
- Retain the original connection, prune preemption, directory lease and shutdown owner until the admitted write completes, even after caller cancellation. Never replay the write.
- Preserve exact committed frontier, rollback/autocommit state, and checkpoint signaling after successful commit.
- Verify normal, cancelled and rejected commits, shutdown ownership, saturated admission, fix removal and a distinct ownership-breaking mutation. Run touched-crate, full repository and hosted gates with independent review.
The initial fix will cover committed-frontier persistence. Other synchronous storage entry points must be assessed separately; this issue does not claim every SQLite operation or a latency target is qualified.
Current source and delivery status — 2026-09-15
Disposition: retained independent report; implementation is excluded from the current delivery. No production fix for this issue has been committed or merged. The experimental working-tree patch is isolated and is not part of #818. Its additional controls and mutations do not establish a dependency of configuration management or a cause of any historical CI latency failure.
SDK main
3194cf3cincludes PR #776. Public native Durable/Async session construction selects the native WAL path. The ordinary SQLite fixture discussed below is a separate existing path. This report does not request replacing native storage, routing native operations through SQLite, changing Async acknowledgements or modifying any performance contract. The original report and its proposed acceptance are retained for traceability; they are not an instruction to expand the configuration work.Original report, evidence and acceptance
A real SQLite commit invoked by
SqliteConsensusLogStore::save_committedblocks unrelated Tokio tasks on a current-thread runtime. The synchronousrun_admitted_sqlite_writehelper correctly preserves borrowed caller scope, but only hands off the scheduler on multithread runtimes. The asynchronous storage entry point needs an owned, bounded dispatch path for current-thread execution.A controlled synthetic test on
0105ef6837f5b3de399be33b97e4644586cdb4acuses the existing fixed-store commit hook and original two-second cleanup fallback. All three multithread controls pass. The three otherwise identical current-thread cases fail: normal commit progress, cancellation while the transaction owns the connection, and rollback following commit rejection. The independent task cannot run until the hook's cleanup fallback returns. No timing allowance was changed. This reproduces a scheduling defect; it does not establish the cause of a separate hosted latency failure.Acceptance:
The initial fix will cover committed-frontier persistence. Other synchronous storage entry points must be assessed separately; this issue does not claim every SQLite operation or a latency target is qualified.