base red: acpmux lose_running reads its slot without an index (panic ratchet indexing_slicing 687 > 686, #30712)
Summary
The Rust panic ratchet is red on feat-cmux-next: acpmux: clippy::indexing_slicing 687 > baseline 686. #30712 (5a0fd07b66c) ends each running process with let p = &mut self.processes[index]; in ProcessTable::lose_running. That is one new indexing hit in lib code.
This PR reads the slot with get_mut and skips a slot that has no row. A running slot always names a row (ProcessTable::insert adds the index only after the push), so the behavior does not change.
Changelog
none
Testing
Command: fleet cmux-ci run --class isolated --script scripts/ci/cmux-tui-rust-check.sh --os linux --arg panic
- Base 34446e1c7d8: RED,
acpmux: clippy::indexing_slicing 687 > baseline 686(step 036017aa63b3b42d7873c1da). - The fix cherry-picked onto 34446e1c7d8 (51118a7f4f2, a scratch branch that I deleted after the run):
panic ratchet pass(step key tf0200-panicv-51118a7f4f2...).
Observed / Not run
- Observed: the two fleet runs above;
prepush-gate.pyhas no new violations; rustfmt --check is clean. - On this PR's own head 7bf145eb742, the fleet panic and test steps cannot run: the newer base has a stale
cmux-tui/Cargo.lock(#31462 addedfs4), and #31654 fixes that. That is why I verified on the scratch commit, which is before #31462. - Not run: the acpmux process tests on this head (blocked by the same Cargo.lock red).
Summary by cubic
Fixes the red Rust panic ratchet on feat-cmux-next caused by ProcessTable::lose_running reading its slot via self.processes[index] (clippy::indexing_slicing 687 > baseline 686, from #30712).
- Reads the slot with
get_mutand skips a slot that has no row; behavior is unchanged becauseinsertalways adds a running index only after pushing a row.
Testing
- The fleet panic step passes on a scratch commit against 34446e1c7d8; on this head it cannot run because the newer base has a stale
cmux-tui/Cargo.lock(#31462), fixed by #31654.