L. C. Hsieh created SPARK-59989:
-----------------------------------
Summary: Pin the Rust toolchain and silence double_must_use on
async_trait traits
Key: SPARK-59989
URL: https://issues.apache.org/jira/browse/SPARK-59989
Project: Spark
Issue Type: Sub-task
Components: Connect
Affects Versions: connect-gateway-0.1.0
Reporter: L. C. Hsieh
Assignee: L. C. Hsieh
main's CI has been failing since 2026-10-04 on a commit that changed nothing
relevant. rust-toolchain.toml pins `channel = "stable"`, so CI picked up the
newly released Rust 1.99.0, whose clippy added the double_must_use lint.
The lint fires on every `#[async_trait]` trait in the workspace. async_trait
expands each method into one returning a `#[must_use]` Pin<Box<dyn Future>>,
and the lint then objects that the inner type -- a Result, Option or String --
is already must-use. The attribute belongs to the macro expansion, not to our
code, so there is nothing in these traits to restructure.
Two parts to the fix.
Pin the toolchain to 1.99.0. A floating channel means CI can turn red on a
commit that changed nothing, at an unpredictable time, whenever upstream Rust
ships a new lint or changes behaviour -- which is exactly what happened. A
pinned version makes the build reproducible between contributors and CI, and
turns a toolchain upgrade into a reviewable change of its own rather than an
event that arrives on its own schedule. The file carries that rationale and
the
steps for moving the pin. The cost is that Rust upgrades become manual; that
seems clearly better than the alternative. MSRV is unaffected: rust-version
stays at 1.82, which is the minimum this compiles with, a separate thing from
the version used to develop and gate.
Allow the lint at the two traits it fires on, with a comment explaining it is
the macro's attribute rather than ours.
Worth flagging a detail about the scope. The CI log named only
crates/routing/src/lib.rs, because cargo stopped after that crate failed.
Reproducing on 1.99.0 locally showed crates/auth/src/lib.rs:60 is affected as
well, so fixing what the log reported would have left CI red on the next run
with a different crate named. Both are fixed here.
Verified on 1.99.0 throughout, since that is what CI resolves to and 1.97.1 --
what a contributor might have locally -- does not reproduce the failure at
all:
- The failure reproduces before the change: 6 errors, matching CI.
- cargo +1.99.0 clippy --workspace --all-targets -- -D warnings is clean
after.
- cargo +1.99.0 fmt --all --check is clean.
- cargo +1.99.0 test --workspace is 204 passed, 0 failed, 10 ignored.
- A bare `cargo` now resolves to 1.99.0 via rust-toolchain.toml and passes,
confirming the pin takes effect for contributors and CI rather than only
when
the version is named explicitly.
This unblocks #43 (SPARK-59973), which is red for this reason and not for
anything in its own diff.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
