Fix berry mode takeover reverting before gates (#468, #369)

[Mikola Lysenko (mikolalysenko)]

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

Fixes #468
Fixes #369

Summary

Switching a yarn berry package between hosted and vendored mode removed
the old mode's wiring before checking whether the new mode could wire
that package. When the new mode then skipped or refused it, the package
ended up patched in neither mode. Both takeovers now run the target
mode's per-package gates first and, on a refusal, leave the existing
mode byte-identical and report the gate's own code. This is what
CLI_CONTRACT.md already promises ("refuses before reverting").

Root cause (shared)

Each berry takeover preflight only covered the project-level gates
(line endings, cacheKey, compressionLevel). The per-package gates ran
after the revert:

• vendored → hosted (commands/scan/hosted.rs, Vendored → hosted takeover on yarn berry deletes the vendored patch, then skips the hosted rewrite when the grant has no yarnBerry10c0 checksum, and still exits 0 "fully hosted" #468): the berry
  rewriter's per-dep redirect_yarn_berry_missing_checksum gate (a grant
  with no yarnBerry10c0 checksum, which vendored mode never needs) ran
  after dispatch_revert_one had deleted the vendored wiring, ledger
  entry and artifact. The run then exited 0 with "now fully hosted".
• hosted → vendored (commands/vendor.rs takeover in
  vendor_records_reusing, reached by scan/get --mode vendored and
  vendor with the service, Hosted → vendored takeover on yarn berry reverts the hosted redirect before a per-package vendor refusal, leaving the package unpatched in both modes #369): resolutions_gate and
  scan_berry_target (another locked version of the name, a user
  resolutions override, non-npm protocol, mixed or duplicate entries)
  ran after restore_upstream had already removed the hosted pin.

Changes

• Core patch/redirect: preflight_yarn_berry_hosted_dep(dep) checks the grant checksum before a fresh vendored → hosted takeover. The ordinary rewrite gate remains unchanged in this PR, so it composes with Fix yarn berry hosted pin leaking npm auth (#404) #465's lock-aware handling of already-complete pins.
• CLI scan/hosted.rs: Berry vendored takeovers run that per-package gate before reverting. Warning deduplication retains each package's detail.
• Core vendor/yarn_berry_lock.rs: yarn_berry_vendor_target_preflight(root, purl, pin, opts) previews the takeover's own upstream restore and runs the backend's resolution and lock-entry gates on the resulting file text. Socket-owned hosted resolutions therefore do not look like user overrides.
• Core upstream restore exposes the staged text in RestoreOutcome.staged_text, including removals; a dry run writes nothing.
• CLI vendor.rs: the per-target preflight runs after the project-level checks and before the real restore. The preview resolves upstream metadata before mutation; the wet restore resolves it again.

Tests

Issue	Regression test (crates/socket-patch-cli/tests/in_process_vendor.rs)	Without fix	With fix
#468	berry_vendored_to_hosted_takeover_keeps_vendored_without_berry_checksum (wet + --dry-run)	FAILED (no redirect_yarn_berry_missing_checksum refusal; takeover announced)	ok
#369	berry_hosted_to_vendored_takeover_runs_package_gates_first (other locked version, user resolutions; wet + --dry-run)	FAILED (vendor_takeover_reverted_redirect, hosted pin gone)	ok

The #369 test passes --patch-server-url so the vendor run recognises
the hosted pin as a takeover. Without it, the run takes the eject path,
which was already safe.

Local runs:

• cargo clippy --workspace --all-features -- -D warnings: clean.
• cargo test -p socket-patch-cli --test in_process_vendor berry_: 6/6 ok.
• scripts/yarn-berry-vex-matrix.sh 4.12.0 (with
  COREPACK_NPM_REGISTRY=https://registry.npmjs.org, because
  repo.yarnpkg.com is blocked in this sandbox): all yarn 4 suites ok. The
  two yarn@2.4.3 legacy-cachekey legs could not get yarn 2 here (it is
  not on the npm registry); they are unrelated refusal tests.
• cargo test --workspace --all-features --no-fail-fast: everything
  passes except:
  • 12 chmod/read-only "write failure" tests, which can't fail under uid 0
    in this sandbox. They fail identically on a main-based branch.
  • mode_migration_npm berry_*_takeover_* (2): they panic in fixture
    setup (mode_migration_npm.rs:351, the test's own reqwest fetch of
    registry metadata hits the sandbox's TLS proxy, UnknownIssuer)
    before any CLI code runs. CI runs them.
• cargo fmt --check reports the same pre-existing diffs as main (CI
  doesn't gate on fmt); the files this PR adds are rustfmt-clean.

Follow-ups

• Vendored pnpm 12 with packageManager set: the two-document pnpm-lock.yaml makes vendor refuse, and vendor --revert, rollback and the hosted takeover half-revert the project and break frozen installs #466 item 4 (pnpm vendored → hosted) is the same takeover-ordering
  shape for pnpm, but its main cause is the two-document pnpm 12 lock.
  It is tracked there and not changed here.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes Yarn Berry hosted/vendored takeover ordering and lockfile restore preview paths; mistakes could leave projects in a broken patch state, but behavior aligns with documented refuse-before-revert contract and is covered by new integration tests.

Overview
Fixes Yarn Berry mode takeovers (#468, #369) so per-package gates run before tearing down the current mode. Previously, reverting vendored or hosted wiring first could leave a package unpatched when the target mode then refused or skipped it.

Vendored → hosted (hosted.rs): Berry takeover refusal now includes preflight_yarn_berry_hosted_dep (grant must have yarnBerry10c0) ahead of vendored revert; refusals are owned/cloned so skip reasons use the gate’s code; duplicate pre_warnings are deduped by full JSON.

Hosted → vendored (vendor.rs + yarn_berry_vendor_target_preflight): After project-level berry checks, a dry-run restore_upstream populates new RestoreOutcome.staged_text; resolution/lock-entry gates run on that preview so user overrides and conflicting lock entries fail with vendor_override_conflict without removing the hosted pin.

Regression tests cover grants missing the berry checksum and hosted→vendored with an extra locked version or user resolutions.

^{Reviewed by Cursor Bugbot for commit 852472c. Configure here.}

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

Ready for review at 83bb9a9 (83bb9a99b1700483279c101984dc18315581381f).

• CI: 96/96 check runs green on the head; 4 skipped by path filters, 0 failing. Mergeable, 0 commits behind main.
• Bugbot: reviewed 83bb9a9 and found no issues. No unresolved review threads.
• Reviewer focus: vendor_records_reusing (hosted → vendored) and commands/scan/hosted.rs (vendored → hosted). Both now run the target mode's per-package gates before reverting the existing mode, as CLI_CONTRACT.md requires ("refuses before reverting"). See tests/in_process_vendor.rs for the byte-identical-on-refusal assertions.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Reviewed 83bb9a99b170. Ready to merge independently from this code review; no standalone changes requested.

No standalone blocking findings. Both takeover directions run the new package/grant refusal gates before reverting the old mode, and the focused tests preserve the previous wiring byte-for-byte on refusals.

Validation: cargo test --locked -p socket-patch-cli --test in_process_vendor berry_ — 6 passed.

Integration with #465 needs a fix. Do not combine #465 and #470 unchanged: their automatic merge is textually clean, but the combined Berry suite fails berry_crlf_takeovers_round_trip_both_directions. The new target preflight rejects the Socket-owned left-pad@npm:1.3.0 resolution added by #465 as vendor_override_conflict. The preflight needs to recognize owned hosted resolutions or evaluate the restored state. I tested the clean combined tree: 5 passed, 1 failed, versus all 6 passing on #470 alone.

[Mikola Lysenko (mikolalysenko)]

Fixed the #465 integration in eca97d9 + 29bbac4, by evaluating the restored state.

• yarn_berry_vendor_target_preflight now dry-runs the takeover's own restore_upstream for the pin. It then runs resolutions_gate / scan_berry_target on the restored package.json / yarn.lock text. That text comes from the new RestoreOutcome.staged_text; files the restore doesn't touch are read from disk. A Socket-owned resolutions pin is gone after the restore, so it can't count as a user override, and the preflight needs no knowledge of Fix yarn berry hosted pin leaking npm auth (#404) #465's ownership rule.
• The Hosted → vendored takeover on yarn berry reverts the hosted redirect before a per-package vendor refusal, leaving the package unpatched in both modes #369 test now mounts the upstream entry the restore reads. Its user-resolutions case now merges into an existing resolutions table. Under Fix yarn berry hosted pin leaking npm auth (#404) #465 the hosted scan has already written one, and the old text insert produced a duplicate JSON key. I also removed a debug eprintln! I had left in that test.

Validation:

• Fix berry mode takeover reverting before gates (#468, #369) #470 alone: in_process_vendor 104/104, including the 6 berry_ tests.
• Fix berry mode takeover reverting before gates (#468, #369) #470 + origin/agent/fix-yarn-berry-hosted-auth-leak merged (clean merge): in_process_vendor 104/104, including berry_crlf_takeovers_round_trip_both_directions.
• Clippy -D warnings is clean. The takeover/rollback/mode-migration suites pass. The only failures are the root-only chmod tests that fail on main in this sandbox.

Trade-offs:

• A berry takeover now resolves the upstream entry twice (a dry run, then the real restore).
• Offline, the dry run can't resolve the entry. The takeover then fails as redirect_revert_failed, not with the check's own code. The hosted wiring stays untouched either way.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

CI on 29bbac4: 459 jobs passed and 1 failed; the rest are still queued (macOS/Windows). The failure is native (ubuntu-latest, 2.3.4), the PDM backtest cell 2.3.4 crlf hosted, check refusalCodeReported. I don't think this PR caused it:

• This push only changes the npm / yarn berry hosted→vendored takeover (plus a field added to RestoreOutcome). It doesn't touch the PDM hosted scan path.
• The same job passed on 83bb9a9, the previous head of this PR, and passes on main (d63ae5f).
• The cell ran for 27.5s, against about 7s for the other hosted cells, and reported no refusal codes at all. That looks like the hosted scan's call to the patch API stalled, not a lock-handling regression.

I couldn't re-run the job: the API returns 403 with this session's credentials. Please re-run native (ubuntu-latest, 2.3.4) once. If it fails again, I'll treat it as real and dig in.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Pushed compatibility fix 852472c7119a0f6f275db9525a1f4111d3875929 and completed the second review pass. The #465 integration blocker is resolved; code review is clear, pending completion of CI at this head.

The latest #465 moves checksum validation so an already-complete pin can retain its stored checksum. #470's eager rewrite preflight conflicted with that change. This commit keeps the unconditional grant check at the fresh vendored → hosted takeover boundary and restores #470's original, equivalent inline rewrite gate. Neither PR needs to absorb the other. Hosted → vendored still checks the staged restored files before changing the project.

Validation: standalone 124 core Berry tests + 6 takeover tests passed. Combined with #465's latest dc9330f4 (including its main merge), 140 core Berry tests, all 7 Berry vendor/takeover tests, the original orphaned-pin/VEX reproduction, and the Poetry/PDM golden checks passed. The current heads merge cleanly at tree a3fbd2fabcf4b712bae7aeade0adb80966d40506. This includes the previously failing CRLF round trip. An independent reviewer also checked the compatibility change.

The historical-installer failures inspected on this head were external patch API HTTP 504s: Poetry 1.2.2/macOS failed before rewriting, and PDM 2.22.4/Linux failed during a rescan. Uploaded artifacts confirm both causes. I retried the affected jobs: Poetry passed; PDM passed as well. Full platform CI is still required.

[Mikola Lysenko (mikolalysenko)]

CI on 852472c: native (macos-latest, 1.2.2) in "Poetry patch compatibility" failed. The 1.2.2 direct hosted cell failed appliedExactlyOne; the other 4 cells in the job passed, including crlf hosted. Most other jobs are still running. I don't think this PR caused it:

• 852472c only changes rewrite_yarn_berry / preflight_yarn_berry_hosted_dep, both berry-only. The Poetry hosted path is untouched.
• The same job passed on 29bbac4 and 83bb9a9, and on recent main commits (bf0e0d1, 73b17db, 1169ae6).
• One hosted cell applying 0 patches while its sibling hosted cell passes looks like the same patch-API flake as the PDM 504 on 29bbac4.

I can't confirm it from here: this sandbox can't reach the patch API or download artifacts, and re-running returns 403. Please re-run native (macos-latest, 1.2.2) (Poetry) once. If it fails again, I'll treat it as real.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

A second Python job failed on 852472c, with the same pattern as the Poetry one above. In native (ubuntu-latest, 2.22.4) (PDM), the 2.22.4 dev hosted cell failed rescanIdempotent. It ran for 35.2s, against 10–19s for the other hosted cells, and the other 40 cells in the job passed. Again, nothing in 852472c touches the PDM path. This is now the third hosted-only cell on a different Python tool in an hour, which points to the patch API being unstable rather than to this PR. Please re-run this job together with the Poetry macOS one.

---

Generated by Claude Code

[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 852472c. Configure here.}

[Mikola Lysenko (mikolalysenko)]

[agent] Status on 852472c: every check is green, including the Poetry (macOS 1.2.2) and PDM (ubuntu 2.22.4) hosted cells that failed earlier and passed on re-run. Bugbot reviewed 852472c and found no issues, and there are no unresolved review threads. This PR is waiting on human review.

---

Generated by Claude Code