Fix gem unwind dropping source-block ! (#1056)

[Mikola Lysenko (mikolalysenko)]

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

Fixes #1056

Summary

Bundler locks a gem declared inside the user's own source "…" do block as name (= v)!, rubygems.org blocks included. The hosted unwind (rollback, remove <purl>) put the declaration back inside that block but always stripped the ! from DEPENDENCIES. The restored pair then didn't match what Bundler writes, so every frozen install (BUNDLE_FROZEN=true bundle install) failed with exit 16 after a "successful" rollback.

Root cause

lock_edit in crates/socket-patch-core/src/patch/redirect/upstream/gem.rs ran entry.strip_suffix('!') on every non-transitive gem. It never checked whether the restored manifest declaration still sits in a source block.

Fix

• lock_edit now takes a DepEntry (Unpin / Keep / Drop) in place of the transitive bool.
• restore_one picks Keep when the hosted block being undone sits inside a user source … do block. That check is in_source_block, a line-level do/end scan that also covers a group nested in the source block and the source(…) do form. Otherwise it picks Unpin (hosted mode added the !) or Drop (transitive append).
• The module docs and the CLI_CONTRACT.md "Hosted unwind coverage" gem row now describe the exception.

Tests (per issue)

• Hosted gem rollback / remove strips the DEPENDENCIES ! of a gem the user declared inside a source "https://rubygems.org" do block, so every frozen install fails after the unwind #1056: upstream::gem::tests::source_block_declaration_keeps_its_bang_through_restore runs the real forward rewrite and then the restore, for a plain source block and for a group nested in a source(…) block. Both come back byte-identical. source_block_detection covers the helper.
• Hosted gem rollback / remove strips the DEPENDENCIES ! of a gem the user declared inside a source "https://rubygems.org" do block, so every frozen install fails after the unwind #1056 e2e: e2e_redirect_gem_build::gem_hosted_unwind_keeps_a_source_block_bang (real Bundler). It runs a hosted scan, an unfrozen converging install, then rollback and remove. The lock and Gemfile come back byte for byte, and a frozen install of a fresh checkout succeeds with the upstream bytes.

Red→green: with the Keep arm disabled, the e2e fails with DEPENDENCIES\n vuln-gem (= 1.0.0) where it expects vuln-gem (= 1.0.0)!. The unit round-trip test failed the same way before the fix.

Commands run

• cargo test -p socket-patch-core --lib gem: 338 passed
• cargo test -p socket-patch-cli --test e2e_redirect_gem_build -- --ignored (Ruby 3.4, Bundler 4.0.15): 29 passed
• cargo clippy --workspace --all-features -- -D warnings: clean
• cargo fmt --all -- --check: clean for the changed files. The only diff is in upstream/mod.rs, which already differs on main.

🤖 Generated with Claude Code

---

Generated by Claude Code

---

Note

Medium Risk
Changes gem lockfile restore semantics for rollback/remove; wrong ! handling breaks frozen Bundler installs, but the change is narrowly scoped and heavily tested.

Overview
Fixes hosted gem unwind (rollback / remove) so Gemfile.lock DEPENDENCIES lines keep Bundler’s ! source pin when the restored gem declaration still lives inside the user’s own source "…" do block (#1056). Previously the unwind always stripped !, so the restored lock no longer matched Bundler’s format and BUNDLE_FROZEN=true bundle install failed after a “successful” restore.

The upstream restore path replaces the transitive-only flag with a DepEntry action (Unpin / Keep / Drop). in_source_block scans the manifest to choose Keep for source-block declarations; hosted-added pins still Unpin, transitive appends still Drop. CLI_CONTRACT.md documents the exception, with unit and ignored e2e coverage for rollback and remove.

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

[Mikola Lysenko (mikolalysenko)]

BugBot review

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

[final reviewer] I disarmed auto-merge at 41bda596 because ci-ok is red on this head. Only hosted-e2e and e2e (ubuntu-latest, e2e_safety_pnpm) fail, which is the main-wide minimist@1.2.2 failure (#1293), not this PR. #1302 fixes it and is in the merge queue now. Once main carries it, merge main in here (no other commits needed) and I'll re-arm auto-merge after CI goes green. The approval still covers this head.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[burn-down agent] Disabled auto-merge before pushing f8c511c (fix for the Bugbot in_source_block finding, plus origin/main with the #1301 minimist repin). The final reviewer re-arms it after re-reviewing.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{Bugbot Autofix is ON. A cloud agent has been kicked off to fix the reported issue.}

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

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

[Mikola Lysenko (mikolalysenko)]

[final reviewer] Not enqueuing. Tanmay Singla (@Tanmay182003), one non-merge commit landed after your approval at 2e0f5800:

• 9b9441de Count keyword blocks when finding a Gemfile source block (redirect/upstream/gem.rs, +32/-1; the Bugbot in_source_block fix)

ci-ok is red on the current head f8c511c2 and 1 review thread is open. Please re-look at that commit once it's green.

---

Generated by Claude Code