What does cargo:resolver_conflict mean?

Cargo found candidate packages but could not build one dependency graph that satisfies every version, feature, source, and native-link constraint.

Cargo error: failed to select a version for <crate>

Q: How do I prevent cargo:resolver_conflict in CI?

Test targeted dependency updates and all workspace members in CI before merging lockfile changes. Keep private mirrors and vendored sources synchronized with the version metadata expected by project manifests. Avoid unnecessarily exact or overly narrow requirements when compatible ranges are appropriate.

Q: How can I manually validate cargo:resolver_conflict?

Save the full resolver output from `cargo check -vv` and identify the first previously selected package and the requirement that rejected it. Use `cargo tree -i ` when the current lockfile still resolves, so you can see every reverse dependency requesting the conflicted crate. Inspect the crate entries in `Cargo.toml`, workspace manifests, `[patch]`, source replacement, and `Cargo.lock` without running a broad update. If CI differs from local development, compare feature flags, target selection, Cargo version, and the exact lockfile used by each environment.

Fix it fast

Most likely: Two version or feature requirements cannot be satisfied by one dependency graph.

Confirm this is your error

Match the output and confirm you are troubleshooting the same failure.

error: failed to select a version for `shared-types`
all possible versions conflict with previously selected packages
error: failed to select a version for `example-crate`
package `service` depends on `example-crate`, with features: `tls` but `example-crate` does not have these features

Check the cause

Run focused checks to identify what is failing in this environment.

cargo check -vv
cargo tree -i <crate>
cargo tree -d

Apply the safe fix

Use the smallest safe change that addresses the confirmed cause.

# Update only after identifying the incompatible parent or locked version.
cargo update -p <crate>

Verify it works

Repeat the relevant checks and confirm the original error is gone.

cargo check --locked
cargo test --locked

Avoid unsafe shortcuts

Keep security and data protections in place while troubleshooting.

Do not delete Cargo.lock before identifying the conflicting requirements.
Do not perform an unreviewed update of the entire dependency graph.

What Broke in the Dependency Graph

This is Cargo refusing to continue with a dependency graph that does not make sense. The important detail is which versions or peer requirements disagree, not just the final error code.

Repair the dependency graph

Try to repair the version graph instead of forcing past it. A successful command with mismatched dependencies is usually just a slower failure later.

Direct requirement conflict:align the top-level version ranges on a release line supported by every direct consumer.

Transitive conflict:update only the parent dependency that introduces the incompatible range, then review the focused lockfile diff.

Missing feature:correct the feature name or select a crate version that actually declares it.

Patch or mirror divergence:make the overridden source expose metadata compatible with every dependent requirement.

Lockfile pin:use a targeted cargo update -p <crate> after proving that the new selection resolves the specific conflict.

Why Resolution Broke

Two packages require semver-compatible versions that Cargo must unify, but their exact ranges do not overlap.

A dependency requests a feature that does not exist on any otherwise compatible published version.

A [patch], private registry, vendor source, or mirror provides a different set of versions than another environment.

A native dependency links constraint allows only one linked library version, but the graph requires incompatible copies.

Prove the Graph Is Clean Again

Re-run the original build or check in the same environment and confirm Cargo produces a graph before downloading or compiling.

Run cargo tree -i <crate> and the project test suite to verify that the selected version and features match the intended dependency path.

Find the first incompatible constraint

Save the full resolver output from cargo check -vv and identify the first previously selected package and the requirement that rejected it.

Use cargo tree -i <crate> when the current lockfile still resolves, so you can see every reverse dependency requesting the conflicted crate.

Inspect the crate entries in Cargo.toml, workspace manifests, [patch], source replacement, and Cargo.lock without running a broad update.

If CI differs from local development, compare feature flags, target selection, Cargo version, and the exact lockfile used by each environment.

How the Cargo resolver reaches a conflict

Cargo walks the full dependency graph, prefers locked and compatible versions, unifies versions where required, and backtracks when a choice blocks another dependency. The command stops before compiling the final graph. The complete error chain, not only the last line, identifies the two requirements or features that cannot coexist.

Keep the Dependency Graph Healthy

To prevent this, test targeted dependency updates and all workspace members in CI before merging lockfile changes, keep private mirrors and vendored sources synchronized with the version metadata expected by project manifests, and avoid unnecessarily exact or overly narrow requirements when compatible ranges are appropriate.

Docs and source code

Cargo Dependency Resolution

Official explanation of version selection, lockfiles, yanked releases, features, and resolver conflicts. - Source

This process is called dependency resolution and is performed by the resolver.

Specifying Dependencies

Official manifest syntax for registry, path, git, and workspace dependencies. - Source

Cargo supports several ways to specify the location of a dependency.