fix: rollback on drop so write conn returns to pool clean (#46)#47
Merged
jjhafer merged 1 commit intosilvermine:masterfrom Apr 23, 2026
Conversation
yokuze
reviewed
Apr 22, 2026
jjhafer
requested changes
Apr 22, 2026
) Dropping an ActiveInterruptibleTransaction without commit/rollback left the write connection in the pool with an open transaction. sqlx pools reuse connections rather than closing them, so SQLite's close-time auto-rollback never fired, and the next acquire_writer() got a connection where BEGIN IMMEDIATE failed with "cannot start a transaction within a transaction". Drop now takes the writer and spawns a tokio task that issues ROLLBACK (and detach_if_attached) before the connection is released to the pool. The rollback task is bounded by a 5 s timeout so a stuck ROLLBACK cannot hold the single-writer permit indefinitely. To eliminate a panic risk at Drop time on threads without a tokio thread-local (notably Tauri teardown after a programmatic app_handle.exit(N) on the main thread), ActiveInterruptibleTransaction captures a tokio runtime handle at construction and uses it unconditionally in Drop. The insert()/remove()/abort_all() paths that previously relied on Drop now roll back explicitly. As defense-in-depth against any other writer path that might leak a transaction (e.g. user code that does BEGIN and returns early), the write pool gets an after_release hook that runs ROLLBACK. The hook treats "no transaction is active" as the expected benign case and instructs the pool to discard the connection on any other ROLLBACK failure, so a broken connection is not handed to the next caller. The plugin's ExitRequested handler no longer short-circuits on programmatic exits (Some(code)). Treating those the same as user-initiated exits means a user-space app_handle.exit(N) — fatal- error handler, auto-updater, Ctrl+C handler — triggers transaction and database cleanup instead of tearing down plugin state with live interruptible transactions still in the map. The original exit code is preserved through the cleanup detour via ExitGuard. CLEANUP_STATE == 2 is used to recognize the ExitGuard-driven re-exit and let it through. Adds a regression test that mirrors the reporter's MCVE plus a second test covering the attached-database drop path. Both wrap the second begin_interruptible_transaction in tokio::time::timeout so a regression in the drop path fails CI fast instead of hanging. Updates the README to document the auto-rollback-on-drop guarantee (including early returns via ?). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
0d9b8b8 to
2751290
Compare
jjhafer
approved these changes
Apr 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Dropping an ActiveInterruptibleTransaction without commit/rollback left the write connection in the pool with an open transaction. sqlx pools reuse connections rather than closing them, so SQLite's close-time auto-rollback never fired, and the next acquire_writer() got a connection where BEGIN IMMEDIATE failed with "cannot start a transaction within a transaction".
Drop now takes the writer and spawns a tokio task that issues ROLLBACK (and detach_if_attached) before the connection is released to the pool. The insert()/remove()/abort_all() paths that previously relied on Drop now roll back explicitly.
As defense-in-depth against any other writer path that might leak a transaction (e.g. user code that does BEGIN and returns early), the write pool gets an after_release hook that unconditionally runs ROLLBACK, ignoring the benign "no transaction is active" error.
Adds a regression test that mirrors the reporter's MCVE: start an interruptible transaction, drop it, start a second one, and assert the second succeeds and only its data commits.
Updates the README to document the auto-rollback-on-drop guarantee (including early returns via ?).