More retries for failed HTTP fetching

[alan-rager-skydio]

Summary

When downloading large packages over degraded connections, errors in downloading can end up not showing up until the unpacking stage of the pipeline, manifesting as BufError that can't be handled with retry mechanisms. See:

• Automatic Retry on Archive Extraction Failure ("unexpected BufError") #8692
• Failed to download distributions with unexpected BufError errors #1710

This is especially frustrating for downloads via HTTP Range requests. It seems like only the first request's status is actually taken into account in request retrying logic. To better handle them, the Reader is wrapped to ensure that subsequent chunks can be retried. Additionally, BufError during unpacking of archives triggers a restart of the download to try to push through connection issues.

Test Plan

The network connection is artificially degraded to simulate the issues seen by people on unreliable WAN:

tc qdisc add dev wlp0s20f3 root netem delay 350ms loss 25% rate 10mbit

Then, a venv is created, and torch is installed into it:

uv venv --python 3.10
uv pip install torch==2.7.0 --force-reinstall --no-cache --no-deps

Since this problem is mainly happening against our internal nexus repo, I'm having a tough time reproducing it against pypi but will see what I can do to induce the issue.

[konstin]

Hi, and thanks for contributing to uv!

While we want something like this, it's hard to verify those changes at the scale of uv, which runs against all sorts of (misconfigured) network and registries. The core logic needs to hand-written, and needs to follow our existing style, e.g. can't use string contains checks for retry behavior and need to document the decision for the specific error types and status codes. We also want to avoid retrying in different places if possible, such as inside and outside the callback.

[codspeed]

Merging this PR will degrade performance by 7.12%

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

❌ 1 regressed benchmark
✅ 4 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	resolve_warm_jupyter	71.4 ms	76.9 ms	-7.12%

---

_{Comparing alan-rager-skydio:rager/rager/more-resilient-streams (65ba182) with main (7c74e08)}

[konstin]

We can revisit this feature in the future. The easiest for us to adopt would be a library that is already used in other projects that implements stream retries, so we don't have to test run it in a critical part of uv.