Stop the tabular workspace connection pool from leaking read-only state

[MikeAlhayek]

The bug

Removing a spreadsheet from a chat produced this in the production logs:

CrestApps.Core.AI.Documents.Handlers.TabularWorkspaceDocumentEventHandler|DEBUG|
Failed to drop tables for document '...' from workspace database.
Microsoft.Data.Sqlite.SqliteException (0x80004005): SQLite Error 8: 'attempt to write a readonly database'.

TabularWorkspace deliberately keeps its connection in PRAGMA query_only = ON and only opens narrow write windows. query_only is connection state, and Microsoft.Data.Sqlite pools connections by connection string without resetting it — so the workspace handed a poisoned connection back to the pool on dispose.

TabularWorkspaceDocumentEventHandler then opened the identical Data Source={path} string, received that connection, and its DROP TABLE failed — while the metadata SELECT immediately before it succeeded, which is exactly the shape of the logged stack trace.

A second, silent defect in the same method: a pooled connection keeps the native SQLite file handle open after Close(), so the follow-up delete of an emptied tabular.db threw IOException into a debug-only log and orphan database files accumulated. TabularWorkspaceHistoryClearedHandler had the same problem.

Both were confirmed empirically before anything was changed — query_only reads back as 1 on a "fresh" connection, and File.Delete throws "used by another process".

The fix

New TabularWorkspaceDatabase owns how the workspace database is located and opened:

• Pooling=false for file-backed workspaces. The workspace holds a single long-lived connection per scope, so pooling bought nothing and cost correctness.
• Open() sets query_only = OFF explicitly, so no caller ever inherits a write state.
• One path builder. The documents/{referenceType}/{referenceId}/data/tabular.db layout was duplicated across four call sites; a drift there would silently orphan databases.

A failed drop leaves a removed document still queryable by the model, so it is now logged as a warning rather than hidden at debug level.

Verification

Two regression tests in TabularWorkspaceDocumentEventHandlerTests, one per defect. They were checked against the pre-fix connection string to confirm they are not vacuous — both reproduce the production symptom (the sales table survives the removal; the database file is not deleted).

Full suite with the fix in place: 3243 passed, 0 failed.

Left alone

DefaultConversationDocumentCleanupService builds the same path independently, but it deletes through IFileStore rather than File.Delete and carries its own path-segment validation, so its shape differs. It benefits from the pooling fix regardless, since there is no longer a lingering handle to block it.

🤖 Generated with Claude Code