The failure
FAIL src/cli/fleet.test.ts > "keeps relay dispatch ownership until the remote PR is published and the issue is parked"
Test timed out in 5000ms
It is not any one PR's regression — it fails on main
Measured by slot-wedge-r2-0902 while trying to land #440, and worth recording
because "CI is red" has been read as a blocker on individual PRs several times
today:
main @ 3d7561a, with none of that lane's changes: the same test fails,
same 5000ms timeout.
- The lane's branch, run 1: the same test, same timeout.
- The lane's branch, run 2: the same test plus a different one (a Slack
reply-route test).
Each rerun failing a different test is the signature of a load flake, not a
regression. The lane's diff touched only src/orchestrator/factory.ts and
factory.test.ts; fleet.test.ts is a file it does not touch.
The mechanism
The suite has no testTimeout configured, so it runs at Vitest's 5s
default. This test sits in a 286-second suite on a machine also running a
fleet of agents, and a loaded runner trips the default.
Why it matters
It makes the package check red on unrelated PRs, so a genuinely-failing PR and
a flake-failing PR look identical. That has already cost review time tonight,
and it trains readers to wave CI through — which is how a real failure gets
merged.
Suggested fix
Give this test (or the suite) a testTimeout proportionate to what it actually
does, rather than the 5s default. If 5s is genuinely the intended budget, the
test needs to stop depending on wall-clock scheduling under load.
Please do not fix it by deleting or skipping the assertion — it covers
dispatch ownership through PR publication, which is exactly the area under
active repair (#430, #440).
The failure
It is not any one PR's regression — it fails on
mainMeasured by
slot-wedge-r2-0902while trying to land #440, and worth recordingbecause "CI is red" has been read as a blocker on individual PRs several times
today:
main@3d7561a, with none of that lane's changes: the same test fails,same 5000ms timeout.
reply-route test).
Each rerun failing a different test is the signature of a load flake, not a
regression. The lane's diff touched only
src/orchestrator/factory.tsandfactory.test.ts;fleet.test.tsis a file it does not touch.The mechanism
The suite has no
testTimeoutconfigured, so it runs at Vitest's 5sdefault. This test sits in a 286-second suite on a machine also running a
fleet of agents, and a loaded runner trips the default.
Why it matters
It makes the
packagecheck red on unrelated PRs, so a genuinely-failing PR anda flake-failing PR look identical. That has already cost review time tonight,
and it trains readers to wave CI through — which is how a real failure gets
merged.
Suggested fix
Give this test (or the suite) a
testTimeoutproportionate to what it actuallydoes, rather than the 5s default. If 5s is genuinely the intended budget, the
test needs to stop depending on wall-clock scheduling under load.
Please do not fix it by deleting or skipping the assertion — it covers
dispatch ownership through PR publication, which is exactly the area under
active repair (#430, #440).