fix(drivers): name a location when the missing-driver error searched nothing

Closed
AN
2mo ago
+41-3

Issue for this PR

Closes #1191

This re-lands #1192, which was merged but never reached main. #1191 is still open because of that, not by oversight.

Type of change

  • Bug fix
  • New feature
  • Refactor / code improvement
  • Documentation

What does this PR do?

Why identical work is reappearing. #1192 was squash-merged into its base branch, fix/warehouse-driver-bootstrap (#1122), rather than into main. #1122 had squash-merged to main 43 seconds earlier — 07:33:38Z versus 07:34:21Z — so main's snapshot was taken before #1192's content existed on that branch. #1122 was the only PR from fix/warehouse-driver-bootstrap, and it is already merged, so nothing was going to carry #1192 across.

The mechanics, if you want to check rather than take my word:

  • #1192's merge commit e005323 has a single parent, c49149a — that is #1122's head, not main. So it is a squash onto the branch, not onto main.
  • git merge-base --is-ancestor e005323 origin/main is false.
  • git merge-base --is-ancestor c49149a origin/main is also false, because #1122 was itself squashed: its content is on main only as the single commit f096d8c.

The GitHub API reports #1192 as merged: true, which is accurate and misleading in equal measure — it merged into the wrong base.

The bug, still present on main today. Drivers are deliberately not shipped, so "driver not installed" is a normal state users hit by design rather than an edge case. driverSearchRoots() returns only directories that exist, so on a machine that has never installed a driver it returns nothing, and the error ends in a bare Searched 0 locations: — a colon with nothing after it, naming nowhere to look.

The fix says plainly that there was nothing to search, and names the node_modules directory the printed install command creates. Resolution behaviour is unchanged: this is the error text and one branch.

The change is #1192's, not a rewrite. It is the cherry-pick of #1192's squashed result onto main. Ignoring blob hashes and hunk offsets, the diff here is byte-identical to that commit's own diff, and it applied with no conflict — which independently confirms main already carries #1122's version of both files. Nothing from #1122 is included; that is already on main.

How did you verify your code works?

First, that the premise is true on live main rather than inferred from the merge graph. On babc7cb, constructing the error with an empty searched list prints:

DuckDB driver not installed.
Install it with the warehouse_install_driver tool, or run:
  npm install --prefix /Users/…/.local/share/altimate-code/drivers duckdb
Searched 0 locations:

with nothing after the colon, and none of this commit's wording. So the defect is live, not historical.

Gates

GateResult
bun run typecheck13/13 successful (--force, so not a cache replay)
analyze.ts --markers --base origin/main --strictok — no upstream-shared files modified
bun run lint5903 warnings, 1 error — identical to main's own baseline, measured by checking out main and re-running. The error is the known pre-existing consistent-return in packages/http-recorder/test/record-replay.test.ts.
packages/drivers225 pass, 0 fail (main baseline is 223; the two added are this change's own)
packages/opencode test/altimate4226 pass, 0 fail

One flaky failure, which is not this change. A first test/altimate run failed sample_setup tool — LLM-facing contract > second call to same target at 5005.74ms. That is the known self-race: the test's execFile probe for the dbt runtime uses a 5000ms timeout and the test's own timeout is also 5000ms, so under load it races itself. It passed on re-run, and the only change on this branch is an error-message string in packages/drivers, which sample_setup does not touch. Pre-existing, worth its own fix, not this PR.

Two tests, unchanged from #1192. The empty case must not render Searched 0 locations: and must name the install directory; the populated case must still list the roots it actually searched. The existing "names the searched roots" test was also tightened to create a real managed root and assert the message contains it.

Not verified by me: Windows. The change is string formatting and path.join, with no platform-specific behaviour, but I did not run it there.

Screenshots / recordings

Not a UI change.

Checklist

  • I have tested my changes locally
  • I have not included unrelated changes in this PR

[!NOTE]
Low Risk
User-facing error strings only in packages/drivers; no changes to install or resolution logic.

Overview
When optional warehouse drivers are missing and driverSearchRoots() returns nothing (typical on first run before any managed node_modules exists), DriverNotInstalledError no longer ends with a useless Searched 0 locations: line. It now states that no searchable locations were found and names the expected managed node_modules path under driverInstallDir(), aligned with the printed npm install --prefix hint.

When roots were actually searched, the message is unchanged: it still lists count and paths. Driver resolution behavior is untouched.

Tests cover the empty-root wording, the multi-root list, and tighten the integration case to assert the managed root appears in the message.

Reviewed by Cursor Bugbot for commit 5e9a168b1d9ca4c8fd3b1d0b9f1bf3ed8b40dd51. Bugbot is set up for automated code reviews on this repo. Configure here.

Summary by cubic

Fixes the missing-driver error so it names a location when no searchable driver locations are found. The error previously ended in a bare Searched 0 locations: with nothing after the colon; it now states that no searchable locations were found and names the expected node_modules directory. This re-lands #1192, which was merged but never reached main. Closes #1191. Resolution behavior is unchanged; only the error message is affected.

Summary by CodeRabbit

  • Bug Fixes

    • Improved missing-driver error messages when no searchable locations are found.
    • Error messages now identify the expected managed driver location for easier troubleshooting.
    • Existing searched-location details remain available when multiple locations are detected.

  • Tests

    • Added coverage for empty and populated driver search paths.