Concurrent CLI processes corrupt each other's on-demand driver installs.
The failure
Eight CLI processes started together, each needing a driver that was not yet installed. They all install into the same managed directory, and they collide:
npm install failed (exit 217) … ENOTEMPTY …
rmdir /root/.local/share/altimate-code/drivers/node_modules/duckdb/…
Why
installOptionalDriverInternal serialises installs through installsInFlight, a Map keyed by target directory:
/** In-flight installs keyed by target directory (see the note above). */
const installsInFlight = new Map<string, Promise<InstallResult>>()
That is a module-level Map, so it serialises installs within one process and cannot see any other. driverInstallDir() resolves to one shared path per machine (<XDG_DATA>/altimate-code/drivers), so N processes run N concurrent npm install --save over the same node_modules tree. npm is not safe against that — one process removes a directory another is writing, and both fail.
Scope
This is not benchmark-specific. It bites any concurrent use of the CLI: a developer with two terminals, a CI matrix on one runner, an editor integration alongside a shell session. The visible result is a driver that reports itself broken on a machine where nothing is actually wrong, which then sends the user to reinstall something that was fine.
What it needs
Cross-process mutual exclusion around the mutation, plus a readiness re-check after acquiring — the process that held the lock has usually just installed the thing everyone else queued for, so the other N-1 should return "already present" rather than each running another npm.
A lock also needs stale handling, since a killed process leaves the lock behind. Two signals are needed, not one: whether the owning PID is still alive (only meaningful on the same host) and age (the only signal available for a lock left by another host sharing a home directory).
Concurrent CLI processes corrupt each other's on-demand driver installs.
The failure
Eight CLI processes started together, each needing a driver that was not yet installed. They all install into the same managed directory, and they collide:
Why
installOptionalDriverInternalserialises installs throughinstallsInFlight, aMapkeyed by target directory:That is a module-level Map, so it serialises installs within one process and cannot see any other.
driverInstallDir()resolves to one shared path per machine (<XDG_DATA>/altimate-code/drivers), so N processes run N concurrentnpm install --saveover the samenode_modulestree. npm is not safe against that — one process removes a directory another is writing, and both fail.Scope
This is not benchmark-specific. It bites any concurrent use of the CLI: a developer with two terminals, a CI matrix on one runner, an editor integration alongside a shell session. The visible result is a driver that reports itself broken on a machine where nothing is actually wrong, which then sends the user to reinstall something that was fine.
What it needs
Cross-process mutual exclusion around the mutation, plus a readiness re-check after acquiring — the process that held the lock has usually just installed the thing everyone else queued for, so the other N-1 should return "already present" rather than each running another npm.
A lock also needs stale handling, since a killed process leaves the lock behind. Two signals are needed, not one: whether the owning PID is still alive (only meaningful on the same host) and age (the only signal available for a lock left by another host sharing a home directory).