GeezerVison

… (residual #131)

Flip the deliberate #131 pinning test
classic_vendor_revert_after_hosted_overlay_is_drift_skipped_and_lossy into
the fixed contract (..._keeps_blob): when every wiring record is
drift-skipped ("left alone"), the blob dir must SURVIVE the revert and the
keep must be surfaced (vendor_artifact_kept) — plus a recovery leg proving
a second revert completes once the drift is undone.

Same contract asserted across the npm-family twins' existing drift tests
(npm_lock / pnpm_lock / yarn_berry_lock / bun_lock / yarn_classic_lock:
revert_leaves_drifted_* now require the artifact dir kept + the keep
warning), two new CLI orchestration tests in in_process_vendor.rs
(run_revert and reconcile must retain the state.json entry, record a
COUNTED Skipped vendor_revert_kept — summary.skipped was 0 even when the
skip event was emitted — and never a Removed), and a new yarn-classic e2e
capstone leg (vendored -> hosted overlay -> vendor --revert keeps the
tarball, the kept tarball still installs after the drift is undone, and
the follow-up revert completes to pristine).

RED: 6 core + 2 CLI + 1 e2e tests fail on current main behavior
(remove_tree runs unconditionally after the restore loop; success prunes
the ledger entry).

Co-Authored-By: Claude Fable 5 <[email protected]>

…ck restore

Residual #131 (strapi campaign, adversarially re-confirmed on main): when
vendor --revert found every recorded lock entry re-resolved (a hosted
patch.socket.dev overlay, a registry re-resolve — anything failing the
uuid-dir ownership gate), revert_recorded_block correctly left the lock
alone with vendor_lock_entry_drifted warnings, but the backend still ran
remove_tree(.socket/vendor/npm/<uuid>/) unconditionally after the restore
loop, and run_revert/reconcile_dropped treated the warning-only success as
"removed": PatchAction::Removed + state.entries.remove + save_state. End
state: the lock still pointed at the drifted target while the artifacts,
the ledger entry holding the only pre-vendor originals, and the tarball
the redirect ledger's recorded `original` fragments reference were all
destroyed — a silent-success data loss with a delayed broken-install
hazard.

Fix, per the orphan sweep's invariant (never delete what something still
references):

- RevertOutcome grows `kept_artifact` plus drift_skipped()/keep_artifact()
  helpers (vendor/mod.rs). keep_artifact() pushes an honest
  `vendor_artifact_kept` warning naming the kept dir and the remediation.
- All five npm-family backends with the unconditional remove shape
  (yarn_classic_lock, npm_lock, pnpm_lock, yarn_berry_lock, bun_lock) now
  skip the remove_tree and mark the keep whenever any wiring record was
  drift-skipped.
- run_revert and reconcile_dropped (cli vendor.rs) honor the signal: the
  state.json entry is retained and the outcome is a COUNTED Skipped event
  (`vendor_revert_kept`) recorded via env.record — fixing the sub-bug
  where summary.skipped stayed 0 while skip events were emitted — never a
  Removed; counts stay uninflated (#166 precedent: advisory warnings keep
  bypassing the counters). Human output gains a "Kept N drifted
  package(s)" line.
- Other RevertOutcome construction sites gain `kept_artifact: false`
  (no behavior change outside the npm family).

Once the drift is undone (vendored lock restored — e.g. a future hosted
revert replaying its recorded originals), the next `vendor --revert`
completes exactly as before: lock restored byte-for-byte, artifacts and
ledger pruned.

GREEN: the 6 flipped core tests, the 2 new CLI orchestration tests, and
the new yarn-classic E1 e2e capstone (drift-skip keep -> kept tarball
still installs -> follow-up revert completes to pristine) all pass;
cargo test -p socket-patch-core clean; clippy --workspace --all-features
clean.

Co-Authored-By: Claude Fable 5 <[email protected]>

cursor Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

…s are not drift

The keep gate (drift_skipped) keyed on vendor_lock_entry_drifted, but the
npm-family backends emitted that same code for records a PREVIOUS partial
revert had already restored or removed: a restored fragment's registry
value fails the uuid ownership gate ("re-resolved since vendoring"), a
removed berry resolutions entry hits "no longer exists; nothing to
remove", and a rekeyed pnpm/berry block restored under its pre-vendor key
misses the recorded-key lookup ("no longer exists; nothing to restore").
After any partial restore, every later `vendor --revert` therefore
re-classified the converged records as drift and kept the artifact dir +
ledger entry forever — the CLI's own "undo the drift and re-run `vendor
--revert` to finish" remediation could never be satisfied.

Teach every left-alone branch in the five keep-gate backends (npm, bun,
pnpm, yarn classic, yarn berry) to recognize the ALREADY-CONVERGED state
as a silent no-op before warning:

- a live fragment equal to the recorded pre-vendor `original` (restored
  in place: npm/bun entries, classic/berry blocks, pnpm overrides /
  importer deps / snapshot refs, berry takeover resolutions);
- for Added records with no original, the key being absent (berry
  resolutions entry/table, pnpm overrides in package.json /
  pnpm-workspace.yaml / the lock's overrides section);
- for the rekeying restores (berry lock entries, pnpm packages/snapshots
  blocks), the recorded original block being live verbatim under its own
  pre-vendor key when the recorded key no longer matches.

drift_skipped() now fires only on genuine third-party drift the user can
still undo, so the kept artifacts + ledger entry are released the moment
the drift is undone — run 2 completes the revert and prunes everything.

Tests: each backend's drift unit test gains a second-run leg (undo ONLY
the drift; already-reverted records must be silent and the revert must
complete), the CLI keep tests now drift to a value that is neither ours
nor the original, and a new CLI test pins that a lock manually restored
to the pre-vendor original converges (counted Removed, ledger pruned) on
the first revert.

Co-Authored-By: Claude Fable 5 <[email protected]>