Driver resolution fails with an unrelated uv_cwd ENOENT when the working directory is unavailable

[anandgupta42]

Summary

On main, if the process's working directory becomes unavailable — deleted or renamed out from under a running process, which makes process.cwd() throw ENOENT … uv_cwd — every optional-driver resolution fails, and the failure is reported as an unrelated uv_cwd error rather than as anything about the driver.

This is not limited to diagnostics. resolveOptionalPackage itself throws, and it is the shared resolution path behind isDriverInstalled, loadOptionalDriver and loadOptionalPackage, so the whole driver subsystem reports a filesystem error about the working directory when asked about a warehouse SDK.

Reproduction

Against babc7cb (current main), forcing the condition rather than staging it — deleting a real working directory does not make process.cwd() throw on macOS, so the condition has to be induced directly:

import { loadOptionalDriver, resolveOptionalPackage } from "packages/drivers/src/resolve.ts"

process.cwd = () => {
  throw Object.assign(new Error("ENOENT: no such file or directory, uv_cwd"), { code: "ENOENT" })
}

resolveOptionalPackage("duckdb")
// THREW: ENOENT: no such file or directory, uv_cwd

await loadOptionalDriver("duckdb", "some-absent-package", async () => { throw ambientEnoent })
// THREW: ENOENT: no such file or directory, uv_cwd

Both throw. Expected: resolveOptionalPackage returns undefined or a resolved path, and loadOptionalDriver reports a driver failure naming what it looked for.

Cause

Two unguarded process.cwd() calls on the failure path.

1. resolveOptionalPackage — the one that matters. The createRequire anchor is built from the working directory:

const require = createRequire(pathToFileURL(path.join(process.cwd(), "noop.js")).href)

The anchor never needed the cwd. Resolution is driven entirely by the explicit paths: [root] argument passed to require.resolve below it, so the base only has to be some absolute file URL. Making it the one thing that can throw turns an unrelated filesystem condition into a total resolution failure.

2. loadDiagnostics builds its cwd=… line the same way, so even with the above fixed, formatting a driver failure would still throw while reporting it.

Both were introduced by #1122 (resolve.ts is new in that PR) and are on main as part of the squash commit f096d8c.

How it was found

Not by looking for it. A test written for a narrower review finding on #1201 — "guard the cwd lookup in loadDiagnostics" — asserted that the driver fault survives an unavailable cwd. With loadDiagnostics guarded, the assertion still failed with uv_cwd, which is what exposed resolveOptionalPackage as the larger instance of the same fault. Worth recording: the narrow finding was correct but understated, and only an end-to-end assertion showed the real scope.

Status

A fix is already carried by #1201 (commit d13f070), which guards both call sites via a shared safeCwd() helper and anchors createRequire at safeCwd() ?? os.tmpdir().

Filing this separately because the fix is currently bundled into a large PR whose locking work has open questions (see #1206), and this bug is independent of all of that. If #1201 is reworked, split, or delayed, this should not be lost with it — it is a small, self-contained fix that stands on its own.

Scope

resolveOptionalPackage and loadDiagnostics in packages/drivers/src/resolve.ts.