A globally installed CLI cannot load any warehouse driver when run from an unrelated working directory.
The failure
Measured on a cold VM against a build containing #1122 and #1192, 8 of 8 trials:
DuckDB driver found at duckdb but failed to load: ENOENT: no such file or directory,
open '<cwd>/usr/lib/node_modules/altimate-code/node_modules/duckdb/package.json'
The install is a global npm install -g, package tree under /usr/lib/node_modules/altimate-code/. The file exists at that path without the <cwd> prefix; it was verified on the machine. Ambient module resolution concatenated the working directory onto an already-absolute path.
Two defects
1. We do not use the location the runtime hands us. The error names the correct absolute path. That is better evidence of where the package lives than anything driverSearchRoots() can infer, and we throw it away. When the binary is not itself inside the package tree — so the execPath walk-up misses — and neither NODE_PATH nor ALTIMATE_BIN_DIR is set, nothing else can find it and the load fails even though the package is right there.
2. The message names the bare specifier as a location. found at duckdb is loadFailure(driver, specifier, …) echoing the specifier, not a path the resolver returned. It reads as "we found it and it would not load", for a package that was never located at all. That wording is why this was first diagnosed as a load-path bug rather than a search-coverage bug, and it routes around the good DriverNotInstalledError message #1192 added, because an ENOENT-shaped ambient error sets ambientBroken and takes the other branch.
Why the existing coverage missed it
The verification for #1198 covered the released-binary shape, the managed install dir, NODE_PATH, and cwd walk-up — all clean. Global npm install -g was on that PR's explicit "not verified" list, and it is the shape the benchmark rig runs in.
For the record: a faithful global-install layout on its own does not reproduce this. With the binary inside the package tree the execPath walk-up finds the driver and it loads. The trigger is an ENOENT-shaped ambient error combined with a binary outside the tree — which is why the shape, not just the install method, needs to be in the matrix.
Not the same as the 2000ms open timeout
#1197 / #1198 is a different failure: the store opens, our own deadline fires. Resolution failures surface in 0–2ms and never as a timeout. These are disjoint.
A globally installed CLI cannot load any warehouse driver when run from an unrelated working directory.
The failure
Measured on a cold VM against a build containing #1122 and #1192, 8 of 8 trials:
The install is a global
npm install -g, package tree under/usr/lib/node_modules/altimate-code/. The file exists at that path without the<cwd>prefix; it was verified on the machine. Ambient module resolution concatenated the working directory onto an already-absolute path.Two defects
1. We do not use the location the runtime hands us. The error names the correct absolute path. That is better evidence of where the package lives than anything
driverSearchRoots()can infer, and we throw it away. When the binary is not itself inside the package tree — so theexecPathwalk-up misses — and neitherNODE_PATHnorALTIMATE_BIN_DIRis set, nothing else can find it and the load fails even though the package is right there.2. The message names the bare specifier as a location.
found at duckdbisloadFailure(driver, specifier, …)echoing the specifier, not a path the resolver returned. It reads as "we found it and it would not load", for a package that was never located at all. That wording is why this was first diagnosed as a load-path bug rather than a search-coverage bug, and it routes around the goodDriverNotInstalledErrormessage #1192 added, because an ENOENT-shaped ambient error setsambientBrokenand takes the other branch.Why the existing coverage missed it
The verification for #1198 covered the released-binary shape, the managed install dir,
NODE_PATH, and cwd walk-up — all clean. Globalnpm install -gwas on that PR's explicit "not verified" list, and it is the shape the benchmark rig runs in.For the record: a faithful global-install layout on its own does not reproduce this. With the binary inside the package tree the
execPathwalk-up finds the driver and it loads. The trigger is an ENOENT-shaped ambient error combined with a binary outside the tree — which is why the shape, not just the install method, needs to be in the matrix.Not the same as the 2000ms open timeout
#1197 / #1198 is a different failure: the store opens, our own deadline fires. Resolution failures surface in 0–2ms and never as a timeout. These are disjoint.