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.

```text
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