Rust Duplicate Dependency Versions Bloat the Build in CI

Two crates in your graph depend on SemVer-incompatible versions of the same package, so Cargo builds both. Usually this just bloats and slows the build, but it turns into a hard type error when a type from one version is passed where the other version’s identically-named type is expected.

What this error means

Builds are unexpectedly slow or large, or you hit a baffling expected struct X, found struct X error where both sides look identical. cargo tree --duplicates reveals the same crate present at two versions.

cargo output

error[E0308]: mismatched types
  --> src/main.rs:10:18
   |
10 |     client.send(req);
   |                 ^^^ expected `http::Request`, found `http::Request`
   = note: `http::Request` (from `http` v1.1.0)
        vs `http::Request` (from `http` v0.2.12)

Common causes

Two incompatible major versions in the graph

One dependency pulls http 0.2 while another pulls http 1.x. They’re distinct crates to Cargo, so types from one don’t unify with the other.

A lagging transitive dependency

An older crate pins an old version of a shared package. Until it’s upgraded, the graph carries both the old and the new version.

How to fix it

Find and collapse the duplicates

List the duplicated versions and who requires each, then upgrade the lagging crate to converge on one version.

Terminal

cargo tree --duplicates
cargo tree -i http   # who requires which version
cargo update -p http

Upgrade or align the requirement

Upgrade the dependency that pins the old version to a release using the new one.
For your own direct deps, bump the requirement so it shares the same major version.
If unavoidable, keep the public API on one version and adapt at the boundary.

How to prevent it

Run cargo tree --duplicates in CI to catch divergence early.
Upgrade related crates together so shared deps stay on one major version.
Avoid exposing a third-party type in your public API across version boundaries.