[Mikola Lysenko (mikolalysenko)]

Problem

The nightly leg e2e-extended (ubuntu-latest, e2e_vex_build, poetry:: --ignored, 1.1.15) failed once (run 39101574188, job 117599202945, 2026-10-18). The failing test was poetry::poetry_hosted_fresh_install_then_manifestless_vex. Its rollback was refused:

six==1.16.0: GET https://pypi.org/pypi/six/1.16.0/json: error sending request for url (https://pypi.org/pypi/six/1.16.0/json)

That is 1 failure in the last 12 nightlies. It is tracked in #1650. It is the only flake seen on main, merge_group or PR runs since 2026-10-17. The only other failures were the uv 0.13.2 pipenv pylock break, already fixed on main by #1605, and the real behavior failures on #1646.

Root cause (why it can't be fixed yet)

UpstreamClient and registry_fetch::download format a transport error with reqwest's Display. That text ends at "error sending request for url (...)" and drops the cause chain. So the log can't tell us whether PyPI refused the connection, reset it, failed DNS or timed out. #1650 proposes a bounded retry, but only if the failure turns out to be a dropped connection or a 429/503. Adding a retry before we know the error class would be guessing.

Fix

This PR adds diagnostics only (step 1 of #1650). The send and body-read errors in UpstreamClient::get_json_authorized and registry_fetch::download now go through api::client::network_error_detail. The patch API client already uses that helper: it appends the cause chain and redacts URLs. The only visibility change is that network_error_detail becomes pub(crate). Users also benefit: a refused hosted restore now says why the registry lookup failed.

No retry is added and no test is removed, moved or weakened. Workflows and required checks are unchanged.

Proof

• New test upstream::client::tests::a_failed_lookup_keeps_the_transport_cause sends get_json and download to a closed local port and requires refused in the error.
  • Without the fix it fails: GET http://127.0.0.1:43369/...: error sending request for url (...).
  • With the fix it passes.
• cargo test -p socket-patch-core --lib -- upstream::client::tests api::client::tests::network_error_detail vendor::registry_fetch: 52 passed.
• rustfmt --check passes on the 3 touched files.
• cargo clippy -p socket-patch-core --all-targets -- -D warnings reports nothing in the touched files. With local toolchain 1.93.1 it reports 26 errors that already exist on origin/main, in other files such as jvm_jar.rs and bun_binary.rs.

Refs #1650

---

Generated by Claude Code

---

Note

Low Risk
Only changes error message formatting for failed registry HTTP calls; no auth, retry, or download logic changes.

Overview
Registry and upstream HTTP failures now surface the full reqwest cause chain (e.g. connection refused, DNS, TLS) instead of stopping at “error sending request for url (...)”.

Upstream restore (UpstreamClient::get_json_authorized) and registry artifact download (registry_fetch::download_unredacted) format send and read errors through the existing network_error_detail helper (URL-redacted), which is now pub(crate) so those paths can share it with the patch API client.

A new async test binds a closed local port and asserts get_json / download errors include a transport cause such as “refused”. No retries or other behavior changes—diagnostics only for #1650.

^{Reviewed by Cursor Bugbot for commit 4f7319c. 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 4f7319c. Configure here.}

[Mikola Lysenko (mikolalysenko)]

coverage (and therefore ci-ok) failed on 4f7319c in e2e_redirect_cargo_build. The runner could not reach static.crates.io (Could not connect to server, 3 cargo retries). That is an external network failure. This PR only changes how registry lookup errors are worded in socket-patch-core and does not touch that test. The failed jobs were already re-run once at 04:40Z, and the flake itself is tracked by #1654. Bugbot found no issues.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: labeled Ready for review.

• Head: 4f7319c
• CI: 35/35 checks green (19 skipped); an earlier coverage failure on this head was a crates.io/static.crates.io network blip and passed on re-run
• Bugbot: reviewed this head (check Cursor Bugbot success), no findings, no open review threads
• Mergeable, no conflicts; no CHANGELOG.md change

Slack announcement not sent: this run has no Slack send tool.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: labeled Ready for review at 4f7319c.

• CI: 35/35 checks green on the head (19 skipped), no main-wide failures.
• Bugbot: reviewed 4f7319c, no findings; no open review threads.
• Mergeable against main, no CHANGELOG changes.
• Slack announcement not sent this run (no Slack send tool available); the next run will retry.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Final review brief (for the approver)

What it does. Registry lookups in the hosted upstream client and the vendored download path now format transport errors with the existing network_error_detail helper, so the error carries the cause chain ("connection refused", reset, timeout, DNS) instead of stopping at reqwest's "error sending request for url (...)". Diagnostics only (step 1 of #1650): no retry, no behavior change beyond the error text.

Risk: low. Three one-line map_err changes plus a visibility bump (fn → pub(crate) fn). URLs in the added cause text go through the same redact_urls_in the patch API client already uses, and registry_fetch::download still redacts the whole message afterwards.

Look here

• upstream/client.rs:253 and :261:``` send and body-read errors
• registry_fetch.rs:961: vendored download send error
• api/client.rs:41: the reused helper (cause chain + redaction)
• upstream/client.rs:906-924:```` new test against a closed local port; asserts "refused" in both get_json and `download` errors (Windows' "actively refused it" text also matches)

Verified. Read the full diff and the helper; checked that download's outer redaction still applies and that no test or workflow changed. CI 54/54 settled on 4f7319c (35 success, 19 path-skipped), ci-ok and clippy green. Bugbot reviewed 4f7319c: no findings; no review threads. Mergeable, up to date with main, CHANGELOG.md untouched.

Changes I made. None.

Open questions. None.

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

---

Generated by Claude Code