agent's cargo audit fix picked a yanked version — the build failed

Not specified by the original author.

TL;DR

The audit tool suggested a version that the author later yanked, and cargo refuses to build it. Pick the nearest non-yanked version (check yank status on the registry first), update the lockfile, and re-run the audit.

Error

agent's cargo audit fix picked a yanked version  -  the build failed on 'version X has been yanked'

Steps

1. Confirm the yank: check the version's status on the registry page for the crate. Expected output: The version is marked yanked, explaining the build failure.

2. Choose the nearest non-yanked version that still addresses the advisory, preferring the smallest move that fixes it. Expected output: A concrete replacement version.

3. Run cargo update -p [crate name] --precise [version] and rebuild. Expected output: The build succeeds and the lockfile pins the non-yanked version.

4. Re-run cargo audit to confirm the advisory is resolved by the replacement. Expected output: No open advisory for the crate.

5. Add a yank check to the agent's fix flow: verify registry status before committing an audit-suggested version. Expected output: The next suggested version is validated before it lands.

When to use

• cargo fails with version X has been yanked after an audit fix
• An automated tool pinned a version the registry no longer serves
• You are hardening an agent's audit-fix workflow

When not to use

• A deliberately yanked-version dependency you need to keep; vendor or fork it
• Audit advisories with no fixed version; that is triage, not a yank problem
• Network or registry outages blocking downloads

Variant phrasings

cargo build fails version has been yanked after update

cargo audit suggested a yanked version

replace yanked crate version in Cargo.lock

Why it happens

Yank status is metadata the audit tool may not have checked when it suggested the version. Between the suggestion and the build, or even before it, the author yanked that version, and cargo treats yanked versions as uninstallable for new lockfiles.

Edge cases

• If your existing lockfile already pins the yanked version, builds keep working until the lockfile changes; the failure appears exactly when you touch it.
• A yanked version can still be the only fix for an advisory; then you need a fork, a patch section, or an exception.
• Audit databases lag yank events; re-check status at apply time, not at suggestion time.

Provenance

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

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

Thread query: agent's cargo audit fix picked a yanked version - the build failed on 'version X has been yanked'

TL;DR: The audit tool suggested a version that the author later yanked, and cargo refuses to build it. Pick the nearest non-yanked version (check yank status on the registry first), update the lockfile, and re-run the audit.

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

pip-audit --fix picks the first version that resolves the CVE, and that version can be yanked: still listed, but its files removed from the index, so every fresh install fails. The rescan passes because the pin satisfies the audit, while the build breaks because pip cannot download the file. List the fix candidates without applying them, skip the yanked ones, and pin the next non-yanked fixed version yourself.

The query

pip-audit --fix pinned to yanked versions - the rescan passed but every build broke

Use this when

• pip-audit --fix changed your requirements and builds started failing on install
• pip reports the pinned version as yanked or cannot find its files
• The rescan is green but nothing installs

Not for

• CVEs with no fixed version available at all (nothing to pin)
• Build failures unrelated to the pinned versions (check the error first)
• pip-audit false positives (a matcher problem, not a fix problem)

Steps

1. See what --fix actually pinned

git diff requirements.txt

Expected output: the version pins --fix wrote. Note each changed package and version.

2. Check which pins are yanked

For each pinned version, check its status on the package index. A yanked release shows a yanked marker; its files may already be gone.

Expected output: a list of which pins are yanked versus healthy.

3. List fix candidates without applying

pip-audit --desc

Expected output: the vulnerabilities with their fix versions listed. You are looking for the next fixed version after the yanked one.

4. Pin the next non-yanked fix by hand

Edit the requirements to the healthy fixed version and reinstall from a clean environment:

pip install -r requirements.txt

Expected output: the install succeeds and pip-audit reports the CVE fixed. The pin is now both green and installable.

5. Verify from a truly clean environment

Build in a fresh container or virtualenv with no cache, the way CI does. Verify: the install and the audit both pass with empty caches.

Variant phrasings

pip-audit fix yanked version breaks build

The short symptom search.

pip-audit --fix pinned version files removed

The cause-first search.

Compatibility: pip-audit with any pip version honoring yanked releases per PEP 592.

Why it happens

Yanked releases stay visible in version metadata but have their files withdrawn, usually because the release itself was broken. pip-audit's fixer resolves against version metadata, where the yanked version looks like a perfectly good fix target. The audit then passes because the pin satisfies the version constraint, while pip fails because there is nothing to download. Two tools, two different definitions of "this version exists".

Edge cases / pitfalls

• A yanked version can become un-yanked, but do not count on it. Pin the healthy version and move on.
• If every fixed version is yanked, the release line is abandoned. Look for the fix in a newer minor or major release, or a fork.
• Pinning to a yanked version that still has files works today and breaks without warning tomorrow. Treat any yanked pin as tech debt with an expiry date of "whenever".
• Record why you skipped the yanked version next to the pin. Otherwise the next pip-audit --fix run will happily re-pin it.

Provenance

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

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

Thread query: pip-audit --fix pinned to yanked versions - the rescan passed but every build broke

TL;DR: pip-audit --fix picks the first version that resolves the CVE, and that version can be yanked: still listed, but its files removed from the index, so every fresh install fails. The rescan passes because the pin satisfies the audit, while the build breaks because pip cannot download the file. List the fix candidates without applying them, skip the yanked ones, and pin the next non-yanked fixed version yourself.