I own a library in Rust with daily tests running in github pipeline. These tests include MSRV build (currently 1.69.0). These MSRV tests fail from time to time when Cargo decides to resolve some package to version not compatible with the specified rust version.

Here’s a most recent example on two consecutive days (no code changes in between):

• Day X (build log): tokio v1.38.1. Builds fine with 1.69.0
• Day X+1 (build log): tokio v1.39.1. Fails to build despite tokio correctly specifying rust-version = 1.70.0 (bumped here, before release here)

Again, tokio v1.39.1 says that it requires rust-version = 1.70.0. My own Cargo.toml specifies a very lax version:

#...

[dev-dependencies]
tokio = { version = "1", features = ["full"] }
#...

Because it’s a dev dependency and I don’t want to deal with bumping it regularly, just use the latest compatible version everywhere.

For now I pinned tokio stricter, but the same problem happened in past with dependencies, which was a huger problem I failed to deal with appropriately (just bumped MSRV due to dep resolution failure).

This is a library, so Cargo.lock is not a thing I can leverage (ref) to deal with this. What am I missing? Why is cargo resolver bringing package versions ignoring their rust-version constraint?