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

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.

1. 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.

1. 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.

1. 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