You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit e9466da
Browse filesBrowse the repository at this point in the historyBrowse files
fix(drivers): stop a 2s deadline failing healthy DuckDB stores, and say so when the client is broken
`warehouse_test` failed on local DuckDB stores with
`Timed out opening DuckDB database "<path>"` at 2002-2061ms, six of seven
within 5ms of exactly 2000. Python opened the same 1.3MB store moments later
and queried it fine, so the store was healthy and the driver's own deadline
was the failure.
The deadline was a hard-coded 2000ms with no way to raise it, and it was not a
performance budget: DuckDB dispatches the open to the libuv threadpool, so the
wait covers queueing behind every other threadpool user in the process. On a
loaded machine a healthy open crosses it, and the driver then rejects and
closes the handle that was about to succeed.
- Default the budget to 30s, overridable per connection (`open_timeout_ms`) or
by `ALTIMATE_DUCKDB_OPEN_TIMEOUT_MS`.
- Fix a live path to the same symptom: the "callback fired synchronously"
sentinel was `undefined`, which is exactly what a success callback invoked
with no arguments passes, so such a callback was recorded and never
replayed and the open hung until the deadline. The sentinel is now a symbol.
- Say what actually happened. The old text named the store and read as "this
file is broken", which sent investigators after the file for hours.
Also, when the client is broken, stop it looking like a bad connection.
`warehouse_test` reported "Connection 'x': FAILED" for a driver that will not
load and for a wrong password alike. It now classifies local-client faults
(`driver_missing`, `driver_open_timeout`, `store_locked`) and renders them as
an unmistakable INFRASTRUCTURE FAILURE with `infrastructure: true` in
metadata, so neither a model nor a reader of a transcript can score broken
infrastructure as a task failure.
Two more real faults found on the way:
- `duckdb` was missing from `trustedDependencies`, so `bun install` never ran
its `node-pre-gyp install` and `lib/binding/duckdb.node` was never fetched.
Every DuckDB call on such a tree fails with "driver not installed" even
though the package is present. Verified both directions in a scratch
install.
- `wrapDuckDBError` replaced DuckDB's lock message with a friendly summary,
discarding the one actionable part — DuckDB names the PID and executable
holding the conflicting lock. It now appends rather than replaces, and
`onOpen` no longer flattens the error to a bare `DUCKDB_LOCKED`.
Tests open a real store on disk; a mock is what missed this. They need their
own `bun test` process, because four files in `test/altimate` install a
top-level `mock.module("@altimateai/drivers/duckdb", ...)` and Bun evaluates
every test file's top level before running any test, so a whole-directory run
silently exercises a fake. Under `ALTIMATE_DUCKDB_E2E=1` a missing or mocked
driver fails the run rather than skipping it, and CI gets a dedicated step.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01VqnuBDGkh1ZT65Ti7e6DHZ
0 commit comments