[chaliy]

What changed

Nightly CI jobs (Pyodide wheel, Miri, ASAN, fuzz) install their pinned nightly explicitly via rustup toolchain install instead of the removed toolchain: action input, which unblocks the dtolnay/rust-toolchain bump. Includes the other two safe bumps from #2847 (pnpm/action-setup, taiki-e/install-action). Supersedes #2847.

Then one consequence of that migration, found while reviewing it: cargo install does not follow a per-command toolchain selection, so both cargo-fuzz installs silently moved onto the pinned stable.

The migrated jobs install nightly alongside a stable default and select it per command (cargo +nightly-2026-10-30 fuzz build). cargo install in those jobs gets stable 1.96.0, where an unpinned source build resolves to the newest release — so an upstream MSRV bump breaks a tree that has not changed. That is exactly the cargo-geiger 0.14.0 failure test_pinned_ci_tools.py was written to prevent (nightly run 259 went red the next morning with the unsafe-code audit skipped).

The test did not catch it because it read the nightly exemption per job: a job that installed a nightly anywhere exempted every source build in it. It now reads per step — a step is exempt only when its own cargo resolves to a nightly (RUSTUP_TOOLCHAIN, or cargo +nightly-…) — and additionally covers bare cargo install run steps, which carry the same hazard in a spelling the test never looked at.

Also re-indents the nightly pin comment the migration orphaned at with: depth in ci.yml, fuzz.yml and nightly.yml.

Why

The dtolnay/rust-toolchain bump in #2847 (5b84223 → d86e0fa) removes the toolchain: input — the action now always installs the rust-toolchain.toml toolchain (stable 1.96.0). Nightly jobs silently got stable: Pyodide wheel failed (can't find crate for core, target never installed), and Miri/ASAN/fuzz would follow. Verified against upstream action.yml: valid inputs are only targets/target/components.

Before / After

The pin test, before the fix was applied (the regression it now catches):

FAIL: test_tools_on_the_pinned_toolchain_pin_a_version (workflow='ci.yml', job='fuzz-check', tool='cargo-fuzz')
  ci.yml:fuzz-check builds 'cargo-fuzz' from source on the pinned toolchain with no
  version; pin it as `tool: name@version` ...

FAIL: test_cargo_install_on_the_pinned_toolchain_pins_a_version (workflow='fuzz.yml', job='fuzz', tool='cargo-fuzz')
  fuzz.yml:fuzz runs `cargo install cargo-fuzz` on the pinned toolchain with no version;
  pass `--version <v>` or run it on the nightly (`cargo +nightly-... install`) ...

After: 4 passed, and 247 repo-script tests green.

Because nightly.yml and fuzz.yml only run on schedule, PR checks cannot exercise them — so both were dispatched on this branch and report here:

• Build wheel (Pyodide/Emscripten) — success (the original failure mode)
• Fuzz Compile Check — success (validates the RUSTUP_TOOLCHAIN route in ci.yml)
• Fuzz Test (×9), Miri, AddressSanitizer, Security Analysis, Python multi-tenant stress soak — dispatched from this branch

publish-python.yml and python.yml both set RUSTUP_TOOLCHAIN on the pyodide build step itself, so the stable default never reaches it.

Risk

• Medium: touches 6 workflow files, but each change is a mechanical install-step swap preserving pins/targets/components.
• What can break: a nightly job if a rustup component name is wrong (Miri adds miri; ASAN adds rust-src) — covered by the dispatched runs above rather than assumed.
• cargo-fuzz declares no rust_version, so the stable install happened to work; the fix is about the next upstream release, not a current break.

Checklist

• Supersedes chore(ci): bump the github-actions group with 3 updates #2847 (close it on merge)
• Per-step nightly exemption covered by tests, including bare cargo install
• Knowledge updated (knowledge/operations/dependencies.md)
• Nightly + fuzz dispatched on this branch rather than assumed
• CI green — required before merge

---

Generated by Claude Code

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	bashkit	671d2d0	Commit Preview URL Branch Preview URL	Nov 07 2026, 01:21 PM

[bashkit-pr-reviewer]

Review summary (head 671d2d04)

Verdict: Good. The only delta since 8292ef96 is ~68 lines in scripts/tests/test_pinned_ci_tools.py, and it fixes the open P2 outright. No findings.

What changed (verified in checkout): env-aware nightly detection — new ENV_EXPR/env_scopes/resolve_env/_is_nightly helpers resolve ${{ env.X }} through step→job→workflow scopes before matching, so the Pyodide jobs' rustup toolchain install ${{ env.RUST_NIGHTLY }} and their RUSTUP_TOOLCHAIN: ${{ env.RUST_NIGHTLY }} opt-in are now recognized (python.yml/publish-python.yml set RUST_NIGHTLY at job level, which is in the resolution scopes). A new meta-test, test_the_detector_follows_an_env_indirection, pins this down: every job with a rustup toolchain install step must be discovered as nightly (with a checked >= 4 non-vacuity guard; 6 such jobs exist), and any install step carrying RUSTUP_TOOLCHAIN must count as on-nightly. The unresolved-reference fallback is safe: matching is case-sensitive, so a dangling ${{ env.RUST_NIGHTLY }} (uppercase) does not match lowercase nightly. Workflow YAML, the Rust stress-test fix, and the knowledge entry are untouched since the last review.

Findings: P0/P1/P2: none. Prior P2 (pinned-ci-tools-nightly-detector-env-spelling): resolved by this push — closing it.

Context read beyond the diff: full test_pinned_ci_tools.py (332 lines), job-level RUST_NIGHTLY definitions in python.yml/publish-python.yml, repo-wide cargo install / rustup-install-step enumeration.

Not reviewed: no production code changed; CI behavior reasoned from YAML only (no builds run per reviewer workflow).

[bashkit-pr-reviewer]

New push re-reviewed (test-only addition). One latent detector gap, non-blocking; the workflow migration itself still looks correct.

[chaliy]

Python multi-tenant stress soak went red here, and it is not this PR's failure — but it is a real one, so I fixed it in 8292ef9 rather than leave it.

It only shows up here because I dispatched nightly.yml on this branch to validate the migration; nightly.yml never runs on PRs. This PR changes no Rust at all, and the job it tripped was added by #2874 earlier today — after nightly run 298 — so it has never run on main, and tonight's nightly would have gone red regardless of this PR.

Not a flake. The cause is exact:

thread '…one_session_reuses_its_budget_across_many_calls' panicked at
  crates/bashkit/tests/integration/python_tenant_stress_tests.rs:180:
  called `Result::unwrap()` on an `Err` value:
  Execution("session exec() call limit exceeded (1000 calls)")

The test loops 10 * rounds() calls in a single session. At BASHKIT_STRESS_ROUNDS=300 that is 3,000 calls, and tenant() takes the default max_exec_calls of 1,000 — so it died on an unrelated session cap at call 1,000 and never reached what it asserts, which is that memory charged in one call is released at its end. PR CI runs 3 rounds (30 calls), which is why nothing caught it.

Reproduced locally at BASHKIT_STRESS_ROUNDS=101 (1,010 calls): fails identically on the cap, and passes with the fix — all 5 tests green.

The fix gives tenant() its own session limits, sized off a single MAX_ROUNDS constant that also bounds BASHKIT_STRESS_ROUNDS, so the soak multiplier and the cap cannot drift apart again the way they just did. nightly.yml is re-dispatched on this branch to show the job green.

Migration validation (the reason for dispatching)

job	result
Fuzz Testing (all 9 targets)	✅ — confirms cargo +nightly-2026-10-30 install cargo-fuzz --locked
Miri	✅ — rustup toolchain install … --component miri
AddressSanitizer	✅ — --component rust-src + -Z build-std
Security Analysis, Advisory Audit	✅
Build wheel (Pyodide/Emscripten)	✅ — the original failure mode
Fuzz Compile Check	✅ — the RUSTUP_TOOLCHAIN route in ci.yml

---

Generated by Claude Code