Fix Bun lockfile inventory skipping hosted pins (#720)

[Mikola Lysenko (mikolalysenko)]

LLM Description written by Claude Code:claude-opus-5-5

Fixes #720

Summary

On a Bun checkout with no node_modules (the usual CI shape), a package whose lock entry is a Socket-hosted pin used to disappear from lockfile discovery. This change makes it visible again, so:

• a hosted re-run re-pins to a superseding patch, where before it reported success, 0 scanned and kept the old uuid;
• scan --mode vendored takes the hosted pin over, where before it reported success, 0 scanned and left the project hosted.

Root cause

The Bun registry views in crates/socket-patch-core/src/vendor/lock_inventory/bun.rs dropped Socket-hosted pins:

• text bun.lock: only registry 4-tuples [spec, registry, {deps}, sha512] were kept, but a hosted pin is the 3-tuple ["name@https://…/name-ver.tgz", {deps}, "sha512-…"];
• binary bun.lockb: records without a registry version were dropped, and a hosted record carries a tarball resolution with no version.

The pnpm, vlt and yarn berry views already keep hosted pins. Bun was the odd one out.

Fix

• Text lock: hosted_pin_entry recognises the hosted URL tuple whose URL leaf is the package's own <bare>-<version>.tgz. It also covers the digest-less 2-tuple that a Bun < 1.3.10 re-save leaves. The check goes through hosted_url_version, the rule VEX discovery already uses to read Bun hosted refs.
• Binary lock: a record with no registry version gets its version from the leaf of its resolution URL, the same way.
• Identity only: both produce name@version with no URL and no verifier, like yarn berry's hosted pins.
  • The pin's URL and sha512 belong to the patched artifact, so they aren't a pristine source a registry fetch could use.
  • The inventory can't apply the hosted-origin policy, so keeping a uuid-bearing URL from a foreign host would make it count as proof that a redirect ledger record is live (vex::discover::redirect_record_live).
  • Ledger liveness and pristine fetches therefore behave exactly as before, and only discovery gains the package.
• Vendored 3-tuples (relative paths) and tarball URLs whose leaf doesn't name the package are still left out.

The first CI run caught the foreign-host problem, from when the entry still carried the URL: e2e_vex_lockfile bun::f_uuid_on_a_non_socket_host_is_not_a_patch failed. 48487cd fixes it, and that suite now passes in CI coverage and 286/286 locally.

Test evidence

Every new test failed on main and passes with the fix:

Issue / flow	Test	Without fix	With fix
#720 text lock (v0, v1 workspace, v2, CRLF, alias/nested keys, workspace-nested, stale-url repin)	lock_inventory::tests::bun_text_hosted_pins_inventory_as_their_registry_package	FAILED	ok
#720 digest-less 2-tuple, scoped pkg; mismatched leaf / vendored excluded	lock_inventory::tests::bun_text_hosted_pin_shapes_and_non_pins	FAILED	ok
#720 bun.lockb hosted record	lock_inventory::tests::bun_binary_hosted_pins_inventory_as_their_registry_package	FAILED	ok
#720 lockfile-only hosted re-run → superseding patch	in_process_vendor_bun_takeover::bun_lockfile_only_hosted_rerun_moves_to_a_superseding_patch	FAILED (scannedPackages 0)	ok
#720 lockfile-only scan --mode vendored takeover	in_process_vendor_bun_takeover::bun_lockfile_only_scan_vendored_takes_over_the_hosted_pin	FAILED (scannedPackages 0)	ok

CI on 48487cd is fully green:

• 449 checks passed and 6 skipped, the usual skips for a PR. That includes coverage, test on all OSes, clippy, hosted-e2e, every Pipenv matrix cell, and all 39 native Bun compat jobs from Bun 0.8.1 to 1.4.2 (the lockfile-only cells passed in both modes).
• hosted-e2e's first attempt died during corepack setup before any test ran; the re-run passed.
• Bugbot found no issues on 48487cd.

Commands run locally (all green):

• cargo clippy --workspace --all-features -- -D warnings
• cargo test -p socket-patch-core --all-features --lib: 4845 passed. 4 unrelated permission tests fail only because the sandbox runs as root.
• cargo test -p socket-patch-core --test redirect_golden --test upstream_restore_golden --test hosted_inventory
• cargo test -p socket-patch-cli --all-features --test e2e_vex_lockfile --test in_process_vendor_bun_takeover --test covgap_commands_scan_hosted --test vendor_eject_bun_lockb --test mode_migration_bun --test e2e_vex_redirect --test vendor_eject_fresh_checkout --test hosted_memory_parity --test hosted_memory_engine --test in_process_scan --test scan_vendor_e2e --test covgap_commands_scan_mod --test e2e_vex

Notes:

• cargo fmt --all -- --check is not clean on main itself, and CI doesn't run it. The changed files are rustfmt-clean individually.
• The npm/pypi/gem wrappers have no lock-inventory logic, so they need no parallel change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01N8TujytRhQrHLiWi5ziPVj

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[agent] Pipenv compatibility / matrix (ubuntu-latest, 2018.11.26 …) failed on 55fffb6. The failing cell is 2020.11.15 | direct | hosted: Pipenv 2020.11.15's own resolver exited 1 (pipenv/utils.py, resolve, SystemExit: 1). The workflow only runs here because lock_inventory/** changed, and this PR touches only the Bun reader. The same workflow passed on 3f03a57 (run 37152051046). That commit's Rust code matches 55fffb6 except for an import move and a doc comment in bun.rs; the rest of the 55fffb6 change is a CLI test file. I've re-run the failed job once. If it fails again I'll treat it as real and dig into it.

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 48487cd. Configure here.}

[Mikola Lysenko (mikolalysenko)]

[agent] hosted-e2e failed on 48487cd during toolchain setup, before any test ran: corepack prepare pnpm@10 couldn't reach https://registry.npmjs.org/pnpm ("Error when performing the request"). This is runner network trouble, not this change. I'll re-run the job once its workflow run finishes; GitHub refuses a re-run while the run is still in progress.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[burn-down agent] Ready for review at head 48487cd.

• CI: 449/455 check runs passed and 6 were skipped (the usual PR skips); none failed. That covers coverage, test on every OS, clippy, hosted-e2e, the Pipenv matrix, and all native Bun compat cells.
• Bugbot: reviewed 48487cd and found no new issues. No review threads are open.
• Merges cleanly: 0 commits behind main.
• Reviewer focus: the hosted pins are inventoried as identity only (name@version, with no URL and no verifier). That keeps ledger liveness and pristine fetches unchanged. See crates/socket-patch-core/src/vendor/lock_inventory/bun.rs.

Slack announcement not sent: this run has no Slack send tool.

---

Generated by Claude Code