.github/workflows/ci.yml uses dtolnay/rust-toolchain@stable for both the test and wasm-build jobs, which resolves to whatever the current Rust stable release is at the time each workflow run executes — not a fixed version. This means a PR that changes nothing Rust-toolchain-related can start failing CI (a new clippy lint firing, a rustfmt style change) purely because Rust itself updated between when the PR was opened and when CI last ran, with no way to distinguish "this PR broke something" from "upstream Rust changed." Pinning to a specific version (ideally sourced from the already-proposed rust-toolchain.toml, so there's one source of truth) would make CI failures attributable to the actual diff again.
.github/workflows/ci.ymlusesdtolnay/rust-toolchain@stablefor both thetestandwasm-buildjobs, which resolves to whatever the current Rust stable release is at the time each workflow run executes — not a fixed version. This means a PR that changes nothing Rust-toolchain-related can start failing CI (a newclippylint firing, arustfmtstyle change) purely because Rust itself updated between when the PR was opened and when CI last ran, with no way to distinguish "this PR broke something" from "upstream Rust changed." Pinning to a specific version (ideally sourced from the already-proposedrust-toolchain.toml, so there's one source of truth) would make CI failures attributable to the actual diff again.