[Mikola Lysenko (mikolalysenko)]

Problem

Nightly CI on main (run 40824880386, 2026-10-29) is red. In test (windows-latest, 2) (job 123285953223), crawler_cargo_e2e fails 2 of its 41 tests every time. These are assertion failures, not a flake:

cargo_home_fallback_to_home_dot_cargo  (crawler_cargo_e2e.rs:169)
  left:  ["C:\\Users\\runneradmin\\.cargo\\registry\\src\\index.crates.io-…"]
  right: ["C:\\Users\\RUNNER~1\\AppData\\Local\\Temp\\.tmpdvaCmb\\.cargo\\registry\\src\\index.crates.io-…"]
empty_cargo_home_falls_back_to_home_dot_cargo  (crawler_cargo_e2e.rs:222)  same shape

The nightly before this one (2026-10-28) passed these tests. PR CI and the merge queue never run the Windows test matrix (it runs only on schedule, dispatch or CI_SCOPE=full), so the queue did not catch this.

Root cause

#1779 (230d493) changed utils::cargo_home::cargo_home() to read the home the way cargo does: only HOME on Unix and only USERPROFILE on Windows. The two integration tests still pointed only HOME at their temp dir. On Windows the crawler therefore resolved the runner's real ~/.cargo.

Fix

Test-only change. A HOME_VAR constant (USERPROFILE on Windows, HOME elsewhere) mirrors the one in cargo_home.rs. The two tests now set, save and restore that variable. Production code is unchanged.

Proof

• Linux: cargo test -p socket-patch-core --test crawler_cargo_e2e gives 42 passed. cargo clippy -p socket-patch-core --test crawler_cargo_e2e -- -D warnings is clean. rustfmt is clean on the touched file.
• Windows: not run locally. PR CI will not run the Windows matrix either, so this is confirmed by the next nightly or a workflow_dispatch of CI on this branch.

Not fixed here (separate problem, same nightly)

test (windows-latest, 1) also fails 3 socket-patch-core --lib tests from #1763/#1764. Two use Unix-only absolute paths for GOWORK (/elsewhere/go.work, /nonexistent/go.work) and one gets a \\?\ verbatim path back. Open PRs #1812 and #1800 touch those files, so this PR leaves them alone. Tracked in a ci-janitor issue.

Where tests run

No test removed or moved.

---

Generated by Claude Code

---

Note

Low Risk
Test-only environment variable handling in integration tests; no runtime or security impact.

Overview
Fixes Windows nightly failures in crawler_cargo_e2e for cargo_home_fallback_to_home_dot_cargo and empty_cargo_home_falls_back_to_home_dot_cargo. After production cargo_home() started resolving home like Cargo (USERPROFILE on Windows, not HOME), those tests still pointed only HOME at a temp dir, so the crawler used the runner’s real ~/.cargo instead of the staged registry tree.

The change is tests only: a HOME_VAR constant mirrors production (USERPROFILE vs HOME), and both tests now save, set, and restore that variable when isolating $HOME/.cargo fallback behavior. No production code changes.

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

---

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 85e3b02. Configure here.}

[Mikola Lysenko (mikolalysenko)]

PR CI is green (ci-ok passed on 85e3b02). Bugbot found nothing.

I dispatched a full CI run on this branch (40831237830) to check the fix on Windows:

• test (windows-latest, 2): success. crawler_cargo_e2e 41 passed, and both cargo_home_fallback_to_home_dot_cargo and empty_cargo_home_falls_back_to_home_dot_cargo are ok. Both failed in last night's nightly.
• Two failures in that run don't come from this PR. They don't affect this PR's required checks, since the run is a dispatch:
  • The e2e (ubuntu-latest, … e2e_redirect_uv_build …) leg timed out connecting to files.pythonhosted.org (Failed to download idna==3.7 … operation timed out). That's a network blip, and this diff touches only a cargo crawler test.
  • test (windows-latest, 1) is expected to fail on the 3 Go workspace unit tests already red on main. That is tracked in Nightly Windows: 3 Go workspace unit tests fail (Unix-only GOWORK paths) #1815.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: labeled Ready for review at 85e3b02c6bc7ce98d7294b805b169981e0f5820e.

• CI: the pull_request CI run is green (ci-ok passed). The red ci-ok on this head comes from the manual workflow_dispatch full run: test (windows-latest, 1) fails on the Go workspace tests that are red on main (main-wide, fixed by Nightly Windows: 3 Go workspace unit tests fail (Unix-only GOWORK paths) #1815/CI: Fix Go workspace tests on Windows (#1815) #1816), and one uv e2e leg hit a pythonhosted.org download timeout. Neither is from this diff.
• Bugbot: reviewed this head, no findings; no open review threads.
• Reviewer focus: test-only change in crawler_cargo_e2e.rs that sets USERPROFILE alongside HOME for the cargo-home fallback tests.
• Slack announcement could not be sent this run (send tool unavailable); the next run will retry.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Final review brief

What it does. Test-only fix for last night's red Windows nightly. #1779 made cargo_home() read USERPROFILE on Windows (as cargo does), but two crawler_cargo_e2e tests still pointed only HOME at their temp dir, so on Windows they found the runner's real ~/.cargo. The tests now set and restore a HOME_VAR constant (USERPROFILE on Windows, HOME elsewhere). No product code changes.

Risk: low. One test file, 12 lines; no runtime code touched.

Look here

• crawler_cargo_e2e.rs:13: HOME_VAR mirrors cargo_home.rs
• crawler_cargo_e2e.rs:152 and :207: set/restore in the two tests

Verified. Read the full diff and the root cause in #1779. PR CI ci-ok and clippy green; Bugbot reviewed this head with no findings; no review threads. The full-scope dispatch 40831237830 ran test (windows-latest, 2) green with both tests ok. That dispatch's own ci-ok is red only from test (windows-latest, 1) (the Go workspace tests, fixed by #1816) and a pythonhosted.org timeout; neither touches this diff and neither is a required check here.

Changes I made. None.

Open questions. None.

Auto-merge is armed, so approving sends it straight to the merge queue.

---

Generated by Claude Code