[nissa-seru]

TL;DR: in test/mcp-modern-outcomes.test.ts, every until gives its event one 60 s bound, sized for a hang, and only the calls meant to time out get a short request deadline. Before, several bounds sat a few seconds above how long their events take on a quiet machine, and a full-suite run on macOS failed one of the file's tests once.

Problem

In a review of #495 on macOS, a full-suite rerun failed mcp-modern-outcomes' R1-1 reconnect row once, and the file passed 3 runs of 3 alone. The reviewer read it as load flakiness. The report named the row, not its failing assertion.

Several of the file's time bounds sat a few seconds above how long their events take on a quiet machine:

• until polled for an event against a wall-clock deadline: 5 s by default, and 3, 8, 9, 12 or 15 s at seven calls. The R1-1 row that reaps before the reconnect waits 5 s for a launch's start and handshake, twice. Three R1-1 rows wait 8 s for outcomes that the transport's 2 s grace after SIGTERM, and again after SIGKILL (STDIO_EXIT_GRACE_MS), puts at 2 to 4 s.
• Two tests gave replies they need a short request deadline. One continuation test ran an error call and a hang call, whose first leg must be answered, under 600 ms. Another ran three concurrent calls under 2000 ms.

None of these bounds asserts how fast something happens. Each only turns a hang into a failure that names it, and a loaded machine can stretch an event past such a bound in a correct run.

Changes

• until takes one bound, WAIT_MS, 60 s, for every call, as the coalescing fixture's REPLY_DEADLINE_MS does. The seven per-call bounds go.
• The two tests that set their own 40 s test timeout no longer do.
• In the continuation test, the hang call gets its own connection with a 1500 ms deadline, and the error call keeps the default. The hang call's second leg is awaited on the server's wire. The concurrent-continuations test takes the default deadline too.
• The test of close() during a reconnect handshake checks the launch's end as the first connect's test does: its child is gone once close() resolves, and close() took under 15 s, not the connect's 30 s. Its 3 s wait goes.
• Every duration the file measures reads the monotonic clock (performance.now()), until's deadline included.
• The coalescing fixture's settles() comment no longer says CI runs without a test timeout.

What each part is for

• One bound sized for a hang. A bound a few seconds above a designed duration fails a correct run when a loaded machine stretches that duration. A 60 s bound fails one only if the event is held back a whole minute, and it still names a wait that never ends, well inside npm test's 10-minute --test-timeout.
• No test timeouts of their own. A test's own timeout cuts it off at that time, whatever --test-timeout says, so the two 40 s timeouts would cut off a hang in those tests before the 60 s bound could name it.
• Short deadlines only on calls meant to time out. callTool gives a whole call, every leg, the connection's requestTimeoutMs. A short one on a call that must be answered turns a reply that a loaded machine holds back into no-response. The hang call's own deadline has to cover its first leg's answer too, so it gets 1.5 s, the room the next test's deadline gives leg 1.
• Awaiting the hang call's second leg. The server logs a leg as it reads it, and the call's deadline doesn't wait for that, so a count read the moment the call fails can miss a leg that a held-back server hasn't read yet.
• The check on close(). close() closes a connect in flight and waits for its cleanup, so the launch's child is gone once it resolves. The old 3 s wait caught a close() that left the child running until the connect's 30 s timeout, and a 60 s wait wouldn't. The new assertions catch that, and a close() that waits out those 30 s as well.
• The monotonic clock. A wall-clock step forward would end a wait early, or inflate a measured duration.
• The fixture's comment. It said CI runs without a test timeout, which npm test's --test-timeout=600000 contradicts.

Tests

• On Linux, test/mcp-modern-outcomes.test.ts passes 43 of 43 on Node 24.22.0 and on Node 20.20.2, twice each.
• The close() check, with close() broken two ways:
  • Waiting out a connect in flight without closing it: the test fails at the new 15 s assertion (close() took 29956.562662 ms, not the connect's 30 s). Main's version of the test passes, in 30.4 s.
  • Neither closing it nor waiting for it: the test fails with the hanging launch is gone once close() resolved. Main's version fails too, at its 3 s wait.
• Probes, run outside the suite:
  • The R1-1 row that reaps before the reconnect, its steps run with the second launch started 6 s late: under the old 5 s bound it fails with in time: the next launch, and under 60 s it passes in 6.4 s.
  • A continuation call that must be answered, its server stopped (SIGSTOP) for 1 s just after the call goes out: under a 600 ms deadline it ends no-response, and under the default it's the error-response the test asserts. With the server stopped for 2.5 s, a 2000 ms deadline does the same.
  • The hang call, its server held back the same way (Phoebe-2419's probe): under 600 ms only its first leg reached the wire when held 400 ms or more. Under 1500 ms both legs do when it's held up to 1000 ms, and only the first when it's held 1400 ms.
• Not reproduced, on Linux at main: the R1-1 rows didn't fail with the test's CPU held to 20%, 7% or 4% of a core, nor in a whole npm test run held to three cores.
• CI on f2d460f5 merged with main 76623a39 (run 39207109452): Build & Test (npm test) passes on Ubuntu and macOS with Node 20 and 24, and the packed release installs on its own.

Not verified

• The report's failure itself. It came once, in a full-suite rerun on macOS with Node 20.20.2. None of the runs above reproduced it, and none of them but CI's ran on macOS. CI's macOS legs pass, which shows the change runs there, not that it removes that run's failure.

Out of scope

• The two assertions that a first connect ends in under 15 s, not the discover probe's 30 s (:360, :367), keep their bound. They assert time on purpose, as the new close() check does.
• The short sleeps that check something didn't happen (:253 and four others) stay. They can't fail a correct run.
• The await on a transport's close event at :347 has no bound, so it can't fail a correct run, and a hang there still fails at a test timeout.
• :426's 1500 ms deadline stays. The test holds the round after leg 1's answer until that deadline passes, so the deadline has to cover leg 1's answer, and a longer one would add its length to every run.
• mcpl-coalesced-content-parity's rows over 1 MiB aren't changed. The report didn't say which of the three failed once in the same run. Only the render row depends on a timer: the product's own 5 s push/render timeout, whose fallback is the designed outcome for a late render. The other two wait on the fixture's 60 s bound.

---

• This change is test-only: it changes test/mcp-modern-outcomes.test.ts and a comment in test/helpers/coalescing-fixture.ts, and no src/ file, so it carries no fragment.

Written by Crispin-2406 (Claude Opus 5.5). Ada-1017 made the design calls, and Phoebe-2419 reviewed it.

Description checked and posted by Lottie-2661 (Claude Opus 5.5).

🤖 Written using Anthropic's Claude Opus 5.5 through the Rookery's tooling, and posted from the shared nissa-seru account.

[greptile-apps]

Required label not found on this PR.