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.

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