[Bug] warehouse_test fails on local DuckDB files; sql_execute then silently returns 0 rows instead of erroring

Start with the warehouse_test and sql_execute entry points and trace how a failed local DuckDB connection is represented and reused. Reproduce the reported sequence, then verify that a valid file opens successfully or that sql_execute surfaces an error instead of returning empty results after a failed test.

Description

warehouse_test fails 100% of the time against local DuckDB file-based warehouses, and — worse — the failure does not surface as a usable error downstream. After a failed warehouse_test, sql_execute against the same connection silently returns (0 rows) for every query, including introspection queries like SHOW ALL TABLES and select * from information_schema.tables, which is an impossible result and gives the agent no signal that the connection is broken.

Steps to Reproduce

1. Add a DuckDB warehouse pointing at an existing .duckdb file:

   warehouse_add({"type": "duckdb", "path": "/abs/path/to/warehouse.duckdb"})
   

   This reports success.
2. Immediately run warehouse_test against the same warehouse.
3. Observe the failure (see error text below).
4. Run sql_execute with any query, including SHOW ALL TABLES or a query against information_schema.tables, against the same connection.

Expected Behavior

Either:

• warehouse_test should succeed against a valid, accessible local DuckDB file (most likely a file-lock or timeout configuration issue when opening the DB), or
• If the connection is genuinely unusable, sql_execute should refuse to run against a connection whose warehouse_test failed, rather than silently returning (0 rows).

Actual Behavior

warehouse_test failed in 7 of 7 invocations observed across independent evaluation sessions, with:

Failed to connect to warehouse '<name>'.
Error: Error: Timed out opening DuckDB database "/path/to/warehouse.duckdb"

After the failed test, every subsequent sql_execute call against the same connection returned (0 rows) — including SHOW ALL TABLES and select ... from information_schema.tables — with no error surfaced. This is silently wrong: an agent has no way to distinguish "empty result set" from "broken connection." In one observed session, the agent then spun for roughly 10,000 seconds before being killed, apparently retrying/investigating with no useful signal. Agents that recovered did so only by abandoning the warehouse tools entirely and shelling out to python3 -c "import duckdb" directly.

Severity: High — this is worse than a loud failure, because it returns a plausible-looking empty result instead of erroring, which can silently corrupt an agent's or user's understanding of the data.

Environment

• OS: macOS (also observed on other platforms in the same evaluation runs)
• CLI version: current
• Warehouse: DuckDB (local file)