[GH-ISSUE #2320] Latest release of `tokio` dependency fails `past-future (1.67.0)` CI job #967

New issue

Closed

opened 2026-03-16 01:06:54 +03:00 by kerem · 2 comments

kerem commented

2026-03-16 01:06:54 +03:00

Owner

Originally created by @justahero on GitHub (Jul 24, 2024).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2320

Describe the bug

Recent CI builds fail the past-future (1.67.0) job with the following error message:

error: package mio v1.0.1 cannot be built because it requires rustc 1.70 or newer, while the currently active rustc version is 1.67.0

The tokio dependency resolves to version 1.39.1 which has been released on 23rd of July, 2024 (yesterday). The mio dependency now resolves to version 1.0.1. tokio's MSRV has been updated to 1.70.0 (from 1.63.0).

To Reproduce
Open a PR to run the CI workflow, see failing CI job for #2318 for example.

Expected behavior
It's expected that the CI workflow passes successfully.

System:

OS: Ubuntu
Architecture: x86_64
Version 22.04
rustc version: 1.67.0

Version:
Crate: hickory-proto
Version: main

Additional context
There are two options, either tokio is fixed to a previous working version in the Cargo.toml (it's currently set to 1.21) or the CI job needs to be updated. Version 1.37.0 has been working fine on my machine so far.

Originally created by @justahero on GitHub (Jul 24, 2024). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2320 **Describe the bug** Recent CI builds fail the [past-future (1.67.0)](https://github.com/hickory-dns/hickory-dns/actions/runs/10074031258/job/27849568662?pr=2318#step:6:439) job with the following error message: > error: package `mio v1.0.1` cannot be built because it requires rustc 1.70 or newer, while the currently active rustc version is 1.67.0 The `tokio` dependency resolves to version `1.39.1` which has been released on 23rd of July, 2024 (yesterday). The `mio` dependency now resolves to version `1.0.1`. `tokio`'s MSRV has been updated to `1.70.0` (from `1.63.0`). **To Reproduce** Open a PR to run the CI workflow, see [failing CI job](https://github.com/hickory-dns/hickory-dns/actions/runs/10074031258/job/27849568662) for #2318 for example. **Expected behavior** It's expected that the CI workflow passes successfully. **System:** - OS: Ubuntu - Architecture: x86_64 - Version 22.04 - rustc version: `1.67.0` **Version:** Crate: hickory-proto Version: `main` **Additional context** There are two options, either `tokio` is fixed to a previous working version in the `Cargo.toml` (it's currently set to [`1.21`](https://github.com/hickory-dns/hickory-dns/blob/main/Cargo.toml#L53)) or the CI job needs to be updated. Version `1.37.0` has been working fine on my machine so far.

kerem closed this issue

2026-03-16 01:07:18 +03:00

kerem commented

2026-03-16 01:07:29 +03:00

Author

Owner

@djc commented on GitHub (Jul 24, 2024):

I'm actually confused why this is failing. We have a Cargo.lock file committed which should make sure that CI uses the same versions of dependencies on every run until we update the lockfile again. So I wonder why that isn't happening here?

@djc commented on GitHub (Jul 24, 2024): I'm actually confused why this is failing. We have a `Cargo.lock` file committed which should make sure that CI uses the same versions of dependencies on every run until we update the lockfile again. So I wonder why that isn't happening here?

kerem commented

2026-03-16 01:07:34 +03:00

Author

Owner

@justahero commented on GitHub (Jul 24, 2024):

The Cargo.toml states

exclude = ["fuzz"]

the failing command in just no-default-features is

cargo  check --manifest-path fuzz/Cargo.toml --all-targets --benches --examples --bins --tests

so it may bypass the one in Cargo.lock after a fresh cargo build.

@justahero commented on GitHub (Jul 24, 2024): The [Cargo.toml](https://github.com/hickory-dns/hickory-dns/blob/main/Cargo.toml#L15) states ```toml exclude = ["fuzz"] ``` the failing command in `just no-default-features` is ```shell cargo check --manifest-path fuzz/Cargo.toml --all-targets --benches --examples --bins --tests ``` so it may bypass the one in `Cargo.lock` after a fresh `cargo build`.

kerem referenced this issue

2026-03-16 02:27:48 +03:00

[PR #967] [MERGED] Release/0.18 #1829