Fix Windows flake in gem global-gemfile refusal e2e

[Mikola Lysenko (mikolalysenko)]

Problem

gem_hosted_global_gemfile_setting_is_refused (crates/socket-patch-cli/tests/e2e_redirect_gem_stale_install.rs) fails now and then on the test (windows-latest, 2) leg. It caused 2 merge-queue evictions on 2026-10-08:

• Cut merge-group CI from ~46 to ~20 min: shard Gradle e2e and test legs, skip test-release in queue, cancel orphaned runs #1133: merge_group run 37817219371 (job 113448830035), 17:31 UTC
• Fix vendored revert reading a removed dependency as drift (#1132, #1140, #1142) #1147: merge_group run 37837758193 (job 113519077240), 20:12 UTC

Neither PR touches gem code. Both failures have the same signature:

panicked at e2e_redirect_gem_stale_install.rs:1027:13:
the global gemfile setting must be refused: {"status":"error","scannedPackages":0, ... "redirect":{..."warnings":[]...}

In the second failure the test ran for about 10.8s (20:19:53 to 20:20:04). Every other test in the binary finished in under a second.

Root cause

The test writes a Gemfile/Gemfile.lock pair plus a global BUNDLE_GEMFILE: Gemfile.next. The scan correctly refuses the lock (gem_lock_unsupported), so the lock contributes no packages. The scan only got as far as the batch call, the redirect stage and the redirect_gem_bundle_gemfile_unsupported refusal because it found the host's globally installed gems through gem env gemdir/gempath. Locally on Linux that gives scannedPackages: 17, all of them system gems.

On Windows runners, gem env (a gem.cmd shim starting Ruby) sometimes takes longer than PROBE_TIMEOUT (10s, utils/process.rs). When that happens the scan finds 0 packages, makes no batch call and runs no redirect, so the expected warning never appears. The test was quietly depending on how fast the CI runner's Ruby install starts.

Fix

Lay the gem down in the project's bundler deployment layout with the existing materialize_installed_gem helper, as the other tests in this file already do. The scan then finds stale-probe-gem without asking the host. The production code path is unchanged. Every assertion is unchanged: refusal code and detail, redirected == 0, Gemfile and lock byte-identical, nothing attested, non-zero exit.

Proof

• Reproduced the CI failure locally by hiding gem from the child process: PATH=/nonexistent on the test binary, on origin/main. Result: FAILED, with the same scannedPackages:0 / empty redirect.warnings envelope as on CI.
• With the fix: 50/50 passes with PATH=/nonexistent (no gem) and 100/100 passes with the normal PATH.
• The whole e2e_redirect_gem_stale_install binary passes (37/37).
• rustfmt --check on the touched file passes, and so does cargo clippy -p socket-patch-cli --test e2e_redirect_gem_stale_install -- -D warnings.

No tests were removed or moved; the test still runs in the same test (*) legs.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Xr7gMxM5ugBStCpk6kJ3V4

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

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 818923f. Configure here.}

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: labeled Ready for review at 818923f.

• CI: all check suites on the head are success (204 check runs, ci-ok success); no main-wide failures.
• Bugbot: reviewed this head (Cursor check success); no unresolved review threads.
• Mergeable, no CHANGELOG.md change.
• Slack announcement not sent this run (Slack send tool unavailable); the next run will retry.

---

Generated by Claude Code