fix(coordinator): run structure and trigger edits on a connection of their own

[datlechin]

Root cause

A structure save and a trigger edit both wrap their DDL in a BEGIN and a COMMIT of their own, and both ran on the session driver: the structure save through executionRoute, the trigger editor straight through driver(for:) with no scope, no pin and no gate at all. The session driver is also the connection a query tab runs on, so when that tab had a transaction open, the edit's BEGIN joined it (PostgreSQL only warns), its COMMIT committed the tab's uncommitted rows along with the DDL, and a failed statement's ROLLBACK threw the tab's work away. MySQL commits implicitly on DDL, so there the tab's transaction was committed without any message at all. Found as a collateral item while working on #2484; the enum label editor from that PR already took the pooled route for the same reason.

Fix

• DatabaseManager.schemaChangeRoute(for:) names the rule: the app's own DDL runs on a pooled connection wherever the engine can open one, and on the session driver only where nothing else can (DuckDB, PGlite and any engine whose second connection would not reach the same database). It is the metadata route under a name that says why.
• The structure save, the trigger editor and the enum label editor all take that route.
• Trigger create, edit and drop carry the structure tab's DatabaseScope and run through withScopedDriver with the .protectedWrite policy, so a Stop cannot cut a half-applied trigger edit and the DDL lands on the tab's database rather than wherever the session driver happens to be. The definition fetch for Edit goes through the metadata route as well.
• History records the tab's database and schema instead of the browse cursor's.

Behaviour change worth knowing

A save that used to join an open transaction on PostgreSQL now waits for that transaction's lock on the table until the connection's query timeout, then fails with the server's timeout error. That is the honest outcome; the old one committed the user's work silently.

Tests

• DatabaseManagerSchemaChangeRoutingTests: rewritten around a pooled fake seeded into MetadataConnectionPool (a DEBUG-only injectEntry, the pool's counterpart to injectSession). Every pooling case asserts the session driver ran nothing and was never switched; the pin tests use a registered single-connection type so the session-driver path is still covered; a new case pins the route choice for pooling, single-connection and server-scoped scopes.
• TriggerApplyExecutionTests: apply and drop run on the pooled stub, in transaction order, and the session stub sees nothing.
• 28 cases pass across the routing, trigger and pool suites.

No UI test: the flow needs a live server with a second connection.

Docs and changelog

docs/features/table-structure.mdx says a save and a trigger change run on their own connection.

Fixed: Structure and trigger edits committing or rolling back a transaction left open in a query tab on the same connection.

https://claude.ai/code/session_014THhVdsUjbCboxNLnQB1dR

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
TablePro	🟢 Ready	View Preview	Sep 3, 2026, 6:06 AM

💡 Tip: Enable Automations to automatically generate PRs for you.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.