Found by the #203 review. The five wiremock harnesses' call() helpers (audit_wiremock.rs:146, tools_wiremock.rs:90, otel_wiremock.rs:350, and the inline call_tool sites in http_transport_wiremock.rs and http_auth_wiremock.rs) await client.call_tool(..) with no deadline, and rmcp's PeerRequestOptions::default() sets none either.
Consequence
A handler that never replies — today, one that panics, since rmcp 3.1.4 drops the task without answering — hangs the test, and with it the whole cargo test --workspace run: cargo runs the bugwarden crate's binaries before bugwarden-core's, so guard_wiremock, which would catch the same defect by panic in-process, never gets to run. Verified with a hand-applied guard.rs:349 - → / mutant under timeout 30.
Under cargo-mutants (#203) this is why the quicksearch_window panic mutants report as TIMEOUT (verdict unknown, five idle minutes each) instead of CAUGHT. The class is wider than those three: CI's first run (33640015379) and a clean local run both count six — guard.rs:732 + → - (duplicate_marker_id, a usize underflow), :972 filter_attachments and :1032 filter_private (→ vec![Default::default()]) — and the :972/:1032 logs show audit_wiremock assertion failures inside the run that then timed out: caught mutants masked by the hang. Which binary-order wins is what makes the count 3 on one run and 6 on the next.
Direction
A per-call deadline in each helper: tokio::time::timeout(Duration::from_secs(N), client.call_tool(..)) with an expect naming the tool, on the pattern the same files already use for bounded waits (otel_wiremock's 8 s collector wait, the 20 s child budgets in binary_user_agent). N must clear the slowest legitimate call under CI load and cargo-mutants' 5× multiplier; 30 s is in line with the existing budgets. It is a test-only change — the production question (what a panicking handler should do) is #253.
Effect on #244: the six timeouts turn into CAUGHT (or into honest MISSED) with no exclude_re. Once this lands, re-run mutants and expect 0 timeouts.
Found by the #203 review. The five wiremock harnesses'
call()helpers (audit_wiremock.rs:146,tools_wiremock.rs:90,otel_wiremock.rs:350, and the inlinecall_toolsites inhttp_transport_wiremock.rsandhttp_auth_wiremock.rs) awaitclient.call_tool(..)with no deadline, and rmcp'sPeerRequestOptions::default()sets none either.Consequence
A handler that never replies — today, one that panics, since rmcp 3.1.4 drops the task without answering — hangs the test, and with it the whole
cargo test --workspacerun: cargo runs thebugwardencrate's binaries beforebugwarden-core's, soguard_wiremock, which would catch the same defect by panic in-process, never gets to run. Verified with a hand-appliedguard.rs:349 - → /mutant undertimeout 30.Under cargo-mutants (#203) this is why the
quicksearch_windowpanic mutants report as TIMEOUT (verdict unknown, five idle minutes each) instead of CAUGHT. The class is wider than those three: CI's first run (33640015379) and a clean local run both count six —guard.rs:732 + → -(duplicate_marker_id, ausizeunderflow),:972 filter_attachmentsand:1032 filter_private(→ vec![Default::default()]) — and the:972/:1032logs showaudit_wiremockassertion failures inside the run that then timed out: caught mutants masked by the hang. Which binary-order wins is what makes the count 3 on one run and 6 on the next.Direction
A per-call deadline in each helper:
tokio::time::timeout(Duration::from_secs(N), client.call_tool(..))with anexpectnaming the tool, on the pattern the same files already use for bounded waits (otel_wiremock's 8 s collector wait, the 20 s child budgets inbinary_user_agent). N must clear the slowest legitimate call under CI load and cargo-mutants' 5× multiplier; 30 s is in line with the existing budgets. It is a test-only change — the production question (what a panicking handler should do) is #253.Effect on #244: the six timeouts turn into CAUGHT (or into honest MISSED) with no
exclude_re. Once this lands, re-runmutantsand expect 0 timeouts.