feat: Add cancel support for batch/script/transaction operations

[dbin0123]

Summary

Add user cancel support for all long-running database operations, not just queries. This includes executeBatch, executeScript, and executeInTransaction commands which are used for DDL operations (CREATE/ALTER TABLE etc.) and data modifications.


Changes

Backend (Rust):

Added execution_id parameter to execute_batch, execute_script, execute_in_transaction Tauri commands
Added cancel_token parameter to execute_statements() and execute_statements_in_transaction() core functions
Added is_canceled() check before each statement execution in loops
Added proper ROLLBACK on cancel for transaction operations
Updated web routes (dbx-web) to support cancel token registration

Frontend (TypeScript/Vue):
Updated tauri.ts, http.ts, api.ts to pass executionId parameter
Updated useDataGridEditor.ts - DataGrid save operations
Updated TableStructureEditor.vue - Structure save operations
Updated ObjectBrowser.vue - Object source save operations
Updated App.vue - Object source save operations
Updated QueryHistory.vue - Rollback operations
Updated SchemaDiffDialog.vue - Schema diff deploy operations

[t8y2]

PR #1519: feat: Add cancel support for batch/script/transaction operations

+376/-91, 20 files | CI: pass | Mergeable: MERGEABLE

🔴 Must Fix

1. executeInTransaction cancellation does not interrupt an active long-running statement on the main native transaction paths. In crates/dbx-core/src/query.rs:1927, :1958, and :1996, the code only checks is_canceled() before starting each statement, then awaits tx.execute, conn.query_iter, or SQLite execute_batch without racing against the cancellation token or invoking the driver-specific interrupt/kill path. A single-statement transaction like SELECT pg_sleep(600) or SELECT SLEEP(600) will keep running until the database returns, so the new cancel support does not work for the exact long-running transaction case this PR targets.

2. The explicit transaction rollback path reuses the already-canceled token, so rollback may never be sent. At crates/dbx-core/src/query.rs:2065, cancellation triggers do_execute(... "ROLLBACK", cancel_token.clone(), ...); because the token is canceled, do_execute/wait_for_query_opt can return Query canceled immediately instead of executing ROLLBACK. The same pattern appears on statement error rollback at :2099 and commit at :2118. Cleanup statements should run through an uncancelable/internal cleanup path, or the pool should be discarded when rollback cannot be confirmed.

3. The frontend generates execution IDs for these operations but does not expose them to the existing cancel flow. For example, apps/desktop/src/App.vue:503, TableStructureEditor.vue:838, SchemaDiffDialog.vue:520, and useDataGridEditor.ts:762 create local IDs, but cancelActiveExecution() only cancels tab.isExecuting or tab.isExplaining via the tab’s stored execution ID (apps/desktop/src/composables/useSqlExecution.ts:129). Users still have no practical way to cancel structure saves, schema diff deploys, data-grid saves, object-source saves, or rollbacks.

🟡 Suggestions

Add targeted tests for canceling executeInTransaction while a statement is currently running, plus a test that verifies explicit transactions actually issue ROLLBACK after cancellation.

✅ Well Done

The PR consistently extends the Tauri and web request shapes for executionId, and the non-transaction executeBatch / executeScript paths are moving in the right direction by passing cancellation tokens into do_execute.

Verdict

Request changes. The wiring is promising, but transaction cancellation and rollback cleanup currently have correctness holes that can leave long-running work alive or leave a connection in an open transaction.