CI: `cargo and fast pytest` flakes on navigation timeouts (~30% of main runs)

[suchintan]

Summary

The cargo and fast pytest job in test.yml fails intermittently on main with navigation timeouts. Over the last 10 runs on main, 3 failed — all three in this same job, none reproducible locally, and each with a different commit underneath. The failures are timeouts waiting for a navigation to settle, not assertion failures, so they look like an environment/timing problem rather than a product regression.

This is currently the main source of red CI on main, and it makes a genuinely-broken branch hard to distinguish from a flake.

Observed failures

Python side (2 of 3), tests/test_rustwright_sync_api.py::test_page_route_fulfill_can_override_fetched_response:

FAILED tests/test_rustwright_sync_api.py::test_page_route_fulfill_can_override_fetched_response
  - rustwright.sync_api.TimeoutError: Page.goto: Timeout 30000ms exceeded.
========== 1 failed, 68 passed, 1205 deselected in 122.02s ==========

Rust side (1 of 3), actor::tests::password_snapshot_masks_same_document_root_replacement_echo:

thread 'actor::tests::password_snapshot_masks_same_document_root_replacement_echo' panicked at src/actor.rs:9102:14:
  navigate actor to root-replacement password echo fixture: Timeout(10000)
test result: FAILED. 85 passed; 1 failed

Common shape

Both are goto/navigate waits against a locally-served fixture that time out under load, in a job that runs the Rust suite and the fast Python subset back to back on one runner. The Python case is the more frequent one and it is a route-interception test, so the navigation depends on the route handler being installed and the fulfill path completing.

Suggested next steps

• Confirm whether the fixture server is fully ready before the navigation starts, rather than relying on the navigation timeout to absorb startup latency.
• Check whether running the Rust suite and the Python subset in the same job starves the browser of CPU; splitting them, or serialising browser-backed tests, would tell us quickly.
• If the timeouts are genuinely load-related, raise the navigation budget for these fixtures specifically rather than globally, so a real hang still fails fast.

Why this matters now

CI red-vs-green is currently not trustworthy on main. Any work that needs a clean baseline has to re-run the job and eyeball which test failed, which is exactly the kind of manual triage that hides a real regression.

[suchintan]

Additional evidence, and it widens the surface described above: this reproduces on a documentation-only change.

A branch touching nothing but README.md and CHANGELOG.md (+10 −2, no code, no build files) failed cargo and fast pytest twice, with a different set of tests failing each time:

Run 1 — 3 failed, 83 passed

thread 'actor::tests::input_tool_select_option_matches_visible_label' panicked at src/actor.rs:9905:14:
  navigate actor to input fixture: Timeout(10000)
thread 'actor::tests::input_tool_single_select_ambiguity_uses_first_dom_value_or_label_match' panicked at src/actor.rs:9940:14:
  navigate actor to input fixture: Timeout(10000)
thread 'actor::tests::post_dispatch_password_fill_timeout_reports_masked_completion' panicked at src/actor.rs:8379:14:
  navigate actor to post-dispatch fill timeout fixture: Timeout(10000)

Run 2 — 1 failed, 85 passed

thread 'actor::tests::input_tool_empty_values_clear_multi_select' panicked at src/actor.rs:10018:14:
  navigate actor to input fixture: Timeout(10000)

What this adds

• It is not a product regression. A diff that changes only Markdown cannot affect actor navigation. Combined with the failing set differing between two runs of the identical tree, this is conclusively environmental.
• The affected set is broader than the two tests named in the issue. Five distinct actor::tests:: cases have now been seen failing this way, all of them on the same navigate actor to <name> fixture: Timeout(10000) path. The right way to think about this is not "these specific tests are flaky" but "any actor::tests case that navigates to a fixture can time out under load" — so a fix targeted at individual tests will just move the failure to a neighbour.
• Ten seconds is the Rust-side budget (Timeout(10000)), versus 30s on the Python side. The Rust cases are therefore the more sensitive detector of the same underlying stall, which matches them showing up more often here.

Practical impact

A docs PR currently cannot get a green run without re-running the job, so there is no way to distinguish "this branch is fine" from "this branch broke something" without reading the failure text every time. That is the cost worth fixing, independent of the root cause.

The suggestion above about the fixture server being fully ready before navigation begins looks like the highest-value thing to check first: every one of these five failures is the navigation to the fixture timing out, not an assertion about what the fixture returned.