fix(drivers): name a location when the missing-driver error searched nothing
Issue for this PR
Closes #1191.
This PR targets fix/warehouse-driver-bootstrap (#1122), not main; it builds on the optional-driver resolver introduced by that PR and includes the latest parent head.
Type of change
- Bug fix
- New feature
- Refactor / code improvement
- Documentation
What does this PR do?
When optional-driver resolution fails and driverSearchRoots() returns an empty list, the old error ended with a dangling Searched 0 locations: line. The first version of this PR improved that line but overclaimed that the driver directory itself did not exist.
The final wording states only what the empty list proves and still gives the user an actionable destination:
DuckDB driver not installed.
Install it with the warehouse_install_driver tool, or run:
npm install --prefix /home/user/.local/share/altimate-code/drivers duckdb
No searchable driver locations were found. Expected managed location: /home/user/.local/share/altimate-code/drivers/node_modules.
When roots exist, the existing Searched N location(s): ... message is unchanged. Resolution, root precedence, package selection, dynamic import, installation, and permissions are unchanged. In particular, the parent branch deliberately excludes project and ancestor node_modules; it retains the consent-gated managed root and explicitly configured/runtime roots.
Review feedback addressed
The empty-list regression test explicitly models the constructor boundary. Forcing driverSearchRoots() to return [] in a unit-test checkout would be host-dependent because executable- or package-adjacent roots may legitimately exist.
A late review found the complementary portability problem in the older non-empty-root test: it asserted Searched without creating any root, so it could fail in a dependency-free checkout. The final test-only commit creates its own managed node_modules root, points ALTIMATE_DRIVER_DIR at its parent, and asserts that exact root. The direct-constructor test still covers the genuine empty-root wording.
Codebase graph tracing confirms that loadOptionalDriver() passes the exact driverSearchRoots() array to DriverNotInstalledError without transformation.
Verification
| Gate | Result |
|---|---|
| Focused resolver tests | 68 pass, 0 fail |
Combined packages/drivers full suite | 225 pass, 0 fail |
| Driver catalogue consistency | 7 pass, 0 fail |
bun run typecheck | 13/13 successful |
git diff --check | pass |
| Three-seat Council consensus review | unanimous ship-after-fix, high confidence |
| Codex Security exact-final-head diff scan | complete coverage, 0 reportable findings |
The source branch was synchronized with final #1122 head c49149a26f using a normal merge. Final reviewed/pushed head: 212f4546a7. No rebase or force-push was used.
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 text only in the drivers package; no changes to resolution, install paths, or security-sensitive logic.
Overview
When optional driver resolution fails and driverSearchRoots() returns no existing directories (common on a first compiled run), DriverNotInstalledError no longer ends with a useless Searched 0 locations: line. It now says that no searchable locations were found and points at the expected managed node_modules path under driverInstallDir(), while keeping the existing Searched N location(s): … wording when roots were actually checked.
The npm install --prefix hint still uses the same install directory (now via a single installDir variable). Resolver behavior is unchanged.
Tests cover the empty-searched message directly (host-independent), assert listed roots when searched is non-empty, and tighten the integration case so the error mentions the managed root.
Reviewed by Cursor Bugbot for commit 212f4546a70255155f5efb4284517f3ab4d2271a. Bugbot is set up for automated code reviews on this repo. Configure here.