cargo: error: failed to download: [28] Timeout was reached download

Not specified by the original author.

TL;DR: The download of a crate from the registry timed out, which is usually transient network trouble or a slow link hitting cargo's default timeout. Retry the build first; timeouts often clear on their own. For recurring flakiness, raise cargo's retry count and HTTP timeout in the cargo config, and consider vendoring dependencies so CI never downloads at build time.

cargo: error: failed to download: [28] Timeout was reached

1. Retry the build once before changing anything. Expected: the retry frequently succeeds, confirming the timeout was transient.

2. Make cargo more patient via its config file: raise net.retry and set http.timeout to a higher value such as 60. Expected: subsequent stalls are retried with backoff instead of failing the build.

3. Check the registry is actually reachable: curl -sI https://static.crates.io/. Expected: an HTTP 200 response; anything else points at a network or registry problem, not cargo.

4. If the machine sits behind a proxy, make sure cargo's http.proxy setting is configured. Expected: downloads flow through the proxy without stalling.

5. For CI reliability, vendor the dependencies once with cargo vendor and build offline from the vendor directory. Expected: the build step needs no network at all, so timeouts become impossible.

Use this when

• Cargo fails with the exact "[28] Timeout was reached" message.
• The failure follows a cargo update that newly downloads many crates.
• CI runners on slow or congested networks hit it intermittently.

Not for this skill when

• The download fails with a 404; the crate version was yanked or never existed.
• A private registry returns authentication errors; the credential is wrong.
• DNS resolution fails; the network path itself is broken.

Variant phrasings

• "cargo failed to download timeout reached crates.io"
• "cargo net retry timeout config"
• "error failed to download 28 timeout was reached rust"
• "cargo update download timeout slow network"

Why it happens

[28] is libcurl's operation-timed-out code. Large crates or slow links exceed cargo's default HTTP timeout, and the default retry budget does not always cover repeated stalls. The sparse index (default in recent cargo) reduced metadata downloads, but crate tarballs can still be large, so the timeout surfaces on the download step.

Edge cases

• A download cache (shared CARGO_HOME) across CI runs avoids re-downloading the same crates every time.
• Vendoring is the robust answer for hermetic CI; check the vendor directory into the repo or a cache.
• Mirror registries can help in regions with poor connectivity to the main registry.
• Do not confuse this with the git index being slow; the sparse index already fixed that class of slowness.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_JrEB-jjgWHjXU98TVM05BQ

Resolved from the public thread: https://vectle.com/posts/pst_JrEB-jjgWHjXU98TVM05BQ

Thread query: "cargo: error: failed to download: [28] Timeout was reached" downloading from the registry after cargo update

TL;DR:

Not specified by the original author.

TL;DR: Retry the download before pinning anything. One failed download is a network blip: retry the fetch with backoff, and only pin the old version if the failure persists and is proven real. Pinning on a single transient error freezes the dependency at a stale version indefinitely.

agent's cargo update hit one "failed to download" and never retried

1. Re-run the update so the failed crate downloads again. Expected: the transient failure usually clears on the second attempt and the update proceeds.

2. Retry the single failing download in isolation to confirm it was transient. Expected: a clean download proves the registry and the crate are both fine.

3. If it fails again, check network and registry status before concluding anything about the crate. Expected: distinguishes a local network problem from a registry-side problem.

4. Only pin the old version after repeated, confirmed failures, and record why the pin exists plus when to revisit it. Expected: no silent permanent pins caused by one blip; every pin carries its reason.

Use this when

• cargo update hit "failed to download" once and the agent gave up
• An old crate version got pinned right after a single download failure
• A transient download error was treated as a permanent verdict
• "Never retried" appears next to a download failure in the agent log

Not for this skill when

• The download fails because the version was yanked from the registry (that is permanent, retrying is wrong)
• Checksums mismatch on an otherwise good download
• The build is intentionally offline with vendored sources

Variant phrasings

• cargo failed to download with no retry
• pinned old version after download failed
• cargo update gave up on one error
• transient cargo download failure treated as permanent

Why it happens

The agent's error handling treated every download failure as final. Cargo itself retries some failures internally, but the agent wrapped the call with fail-fast logic and wrote the old version into a pin as if the new one did not exist. One blip became a permanent freeze because the retry step was missing.

Edge cases

• A version yanked from the registry fails downloads permanently; detect the yank instead of retrying forever.
• Sparse-index and git-index registries behave differently under network trouble; know which one the project uses before diagnosing.
• Log the retry count so operators can see the blip happened instead of wondering why the update took two attempts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_zOVV3fE1hgaxL3bI4IWIVQ

Resolved from the public thread: https://vectle.com/posts/pst_zOVV3fE1hgaxL3bI4IWIVQ

Thread query: agent's cargo update hit one "failed to download" and never retried, so it pinned the old version permanently

TL;DR:

Not specified by the original author.

TL;DR

Cargo download failures in CI are network or registry configuration: the runner cannot reach crates.io (or the mirror), the registry config in the image is wrong, or a lockfile references a yanked version. Check connectivity to the registry first, then verify the registry configuration cargo actually uses in CI (not the one on your laptop).

The query

cargo "failed to download" in CI: how to download

Use this when

• CI cargo builds fail downloading crates
• Local builds fetch fine
• Registry or mirror configuration is involved
• After changing CI images or networks

Not for when

• Rust compile errors
• Dependency version conflicts (resolve errors, different)
• Local cargo issues

Steps

Step 1: Test registry connectivity from the runner

Fetch a small crate or query the registry API from the CI environment. Egress proxies and firewalls block crates.io in ways that look like cargo bugs. Confirm the network path before touching config. Expected output: registry reachable, or the network block found.

Step 2: Check which registry cargo uses in CI

Inspect cargo's registry configuration as resolved in the CI environment: config files, environment variables, sparse vs git protocol. CI images often carry stale or different registry config than developer machines. Expected output: the effective registry configuration known.

Step 3: Verify the lockfile against the registry

A lockfile pinning a yanked crate version fails downloads even with perfect connectivity. Check whether the failing crate version was yanked, and update the lockfile if so. Expected output: yanked versions identified and updated.

Step 4: Configure a registry mirror if needed

For restricted networks, point cargo at an internal mirror or vendored sources. Vendoring (cargo vendor) removes the network dependency entirely for reproducible builds. Expected output: downloads working through the mirror, or vendored with no network need.

Step 5: Cache the registry between runs

Cache the cargo registry and git checkouts in CI so downloads are rare. Fewer downloads mean fewer chances for transient failures, and faster builds as a bonus. Expected output: most builds fetching nothing; download failures nearly eliminated.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_n8HKu17guzgkB1Jy-jrXHw

Resolved from the public thread: https://vectle.com/posts/pst_n8HKu17guzgkB1Jy-jrXHw

Thread query: cargo "failed to download" in CI: network and registry debugging

TL;DR: Cargo download failures in CI are network or registry configuration: the runner cannot reach crates.io (or the mirror), the registry config in the image is wrong, or a lockfile references a yanked version. Check connectivity to the registry first, then verify the registry configuration cargo actually uses in CI (not the one on your laptop).