Vendored re-run on an isolated-linker bun.lockb writes two package records with the same local tarball, so frozen installs on Bun 1.3.9/1.4.2 fail intermittently with EEXIST #861

[agent] Found by the scheduled Bun bug-hunt routine (ledger #306).

Summary

After a project vendors a patch into a workspace bun.lockb, a new dependent of the patched package (a new workspace member, or bun add in a member) makes Bun write a second, nested registry record of the same name@version. Bun does this because the hoisted record is now a local tarball. The advised fix is a vendored re-run. It rewires that nested record to the same .socket/vendor/...tgz path and integrity as the first one. Bun's own writer never produces two package records with an identical tarball resolution. On the isolated linker, both records map to the same node_modules/.bun/left-pad@.socket+vendor+…tgz store dir, and bun install --frozen-lockfile fails about half the time:

EEXIST: File exists: failed to link package: left-pad@.socket/vendor/npm/<uuid>/left-pad-1.3.0.tgz (link)
1 package installed
Failed to install 1 package        (exit 1)

scan --mode vendored reports success (applied), and vendor --check exits 0 afterwards. An unfrozen bun install fails the same way and leaves bun.lockb unchanged, so nothing heals it.

Impact

CI breaks nondeterministically on a lock that socket-patch reported as successfully vendored. When the link fails, the member's node_modules/left-pad link is missing. The member only resolves the package because Node's lookup happens to walk up to the root copy.

Repro (Linux, main 6811b4e)

The patch API mock is the mock.py from the bug-hunt probe workflows: left-pad@1.3.0 with a marker prepended to index.js, served on 127.0.0.1:8787.

unset BUN_OPTIONS
API="--api-url http://127.0.0.1:8787 --org o --api-token x"; export SOCKET_PATCH_SERVER_URL=http://127.0.0.1:8787
mkdir -p w/packages/a && cd w && git init -q
echo '{"name":"root","version":"1.0.0","private":true,"workspaces":["packages/*"],"dependencies":{"left-pad":"1.3.0","a":"workspace:*"}}' > package.json
echo '{"name":"a","version":"1.0.0","dependencies":{"left-pad":"1.3.0"}}' > packages/a/package.json
printf '[install]\nsaveTextLockfile = false\n' > bunfig.toml; printf 'node_modules\n' > .gitignore
bun install                                   # Bun 1.4.2: binary bun.lockb, isolated linker (workspace default)
socket-patch scan --mode vendored --yes $API  # success
mkdir -p packages/c && echo '{"name":"c","version":"1.0.0","dependencies":{"left-pad":"1.3.0"}}' > packages/c/package.json
bun install                                   # adds a nested registry record c/left-pad@1.3.0 (expected)
socket-patch scan --mode vendored --yes $API  # success, "applied": rewires c/left-pad to the same local tarball
bun bun.lockb                                 # yarn dump: two "left-pad@1.3.0" records, identical resolved/integrity
git add -A && git commit -qm v && git clone -q . ../cl && cd ../cl
for i in 1 2 3 4 5 6 7 8; do rm -rf node_modules packages/*/node_modules; BUN_INSTALL_CACHE_DIR=$PWD/.c$i bun install --frozen-lockfile >/dev/null 2>&1; echo $?; done
# about half the runs exit 1 with EEXIST

Expected vs actual

• Expected: docs/testing/bun-compatibility.md and CLI_CONTRACT.md promise that a vendored lock frozen-installs the patched bytes from a fresh checkout, and that a re-run picks up newly added registry copies. A re-run should leave a lock Bun can install: one record per resolution, with the nested dependency pointing at the existing tarball record.
• Actual: the re-run duplicates the record, and frozen installs fail intermittently with exit 1.

Matrix (Linux; cold-cache fresh clone; vendored re-run after a new member)

macOS/Windows untested (no probe branch this run). There's no release baseline for bisecting, because 4.0.0 refuses vendored bun.lockb.

Suspect code

crates/socket-patch-core/src/vendor/bun_binary.rs:105-118: the for package in matches loop calls lock.set_package(package.id, &staged.rel_tgz, …) on every matching record. Where a record already holds that resolution, the dependency could point at it, or the duplicate could be merged, instead of creating a second record with the same tarball.

Backlog review — 2026-10-08

Priority: P1 → P2. Bun binary-lock EEXIST/install failure is visible and recoverable, rather than silent security success.