Skip to content

ci: cargo-fmt job pins a nonexistent Rust toolchain and fails on every Rust PR #952

Description

@inureyes

Problem

The cargo-fmt job in .github/workflows/ci.yml fails on every pull request that touches Rust, before it runs cargo fmt at all. It fails while installing the toolchain:

info: syncing channel updates for 1.100.0-x86_64-unknown-linux-gnu
error: could not download nonexistent rust version `1.100.0-x86_64-unknown-linux-gnu`:
  ... rust-1.100.0-x86_64-unknown-linux-gnu.tar.gz.sha256 ... 404

Cause

bdad23287 ("ci(deps): bump dtolnay/rust-toolchain from 1.93.1 to 1.100.0") bumped the action reference:

- uses: dtolnay/rust-toolchain@1.100.0

For this action the git tag IS the toolchain version: dtolnay/rust-toolchain@1.93.1 installs Rust 1.93.1. The bump therefore asks for Rust 1.100.0, which does not exist. The latest stable is 1.93.1.

This is a dependabot bump of an action whose tags are toolchain versions rather than action releases, so version-bump automation reads them as ordinary semver.

Impact

Every PR with needs.changes.outputs.rust == 'true' gets a red cargo-fmt check that says nothing about the PR's formatting. Observed on at least PR #951, PR for #947, and the molmo XLA branches. Local cargo fmt --all -- --check passes on those branches, so the signal is purely spurious, which is the worst kind: it trains reviewers to ignore a red fmt check.

.github/workflows/pipeline-parallel-ci.yml:107 also requests clippy, rustfmt components and should be checked for the same pin.

Proposed fix

Pin the action back to a real toolchain version (dtolnay/rust-toolchain@1.93.1, or @stable), and either exclude dtolnay/rust-toolchain from dependabot updates or add a comment at the uses: line stating that the tag is a toolchain version and must name a released Rust.

Acceptance criteria

  • cargo-fmt installs a toolchain and actually runs cargo fmt --all -- --check on PRs.
  • Every dtolnay/rust-toolchain@ reference in .github/workflows/ names a released Rust version.
  • Dependabot cannot silently re-break the pin, or the constraint is documented at the reference so a reviewer catches it.

Activity

  1. added
    type:choreMaintenance tasks (build, CI, etc.)
    and removed on Jul 28, 2026
  2. added a commit that references this issue on Jul 30, 2026
    e385bd8
  3. self-assigned this
    on Aug 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions