[nissa-seru]

Three tests in test/mcpl-request-timeout.test.ts slept a fixed time for a stub server's late reply, so a loaded runner could fail them. The stub now holds the reply until the test's next tools/list, so the test decides when the late reply comes. A fourth test in the file, which passed whether or not requestTimeoutMs: 0 disabled the watchdog, now checks past any delay a watchdog could have.

!Fixes #478

Problem

• "a mandatory call deadline overrides requestTimeoutMs: 0 and surfaces its late response" sleeps 350 ms for a reply the stub sends 300 ms after the call. CI for cabf3d0 failed it on macOS with Node 24, with actual: [] (Flaky test: "a mandatory call deadline overrides requestTimeoutMs: 0" races a fixed sleep against a child's 300 ms reply #478).
• On main at e670363 (Linux, Node 24.22.0), we ran the file's three tests that sleep for a late reply against the built McplServerConnection, with the reply moved past each test's sleep:
  • that test sees no orphaned-response;
  • "a late STATEFUL orphaned response is surfaced via mcpl:orphaned-response", a reply at 500 ms against a 600 ms sleep, sees none either;
  • "a timed-out request that later receives a response does not crash" passes even when the reply comes at 5000 ms, after the test has finished. A late reply with no state, to a call with no deadline, emits nothing the test could wait for.
• Two of those tests then call tools/list on a connection whose requestTimeoutMs is 100, so that call can time out on a slow runner as well.
• "requestTimeoutMs: 0 disables the per-request watchdog" waits 300 ms and checks that the call is still pending. The default timeout is 60 s (DEFAULT_REQUEST_TIMEOUT_MS), so the test passes just the same when 0 falls back to the default. With the ?? where the connection reads the setting changed to ||, it still passes.

Changes

• The shared stub can hold a tools/call reply. Its next tools/list answer writes the held reply first, and then says so in the tool's description.
• The three tests have the stub hold the reply, and call sendToolsList() after the rejection. The connection handles the stub's lines in order, so by the time the list resolves, the late reply has been handled: surfaced as orphaned-response, or ignored. Each test checks that the list's answer says a held reply went first. The reply can't arrive before the timeout either, since the stub sends it only when the test asks.
• In the two tests whose connection times out at 100 ms, the test lifts the connection's request timeout after the rejection, so the releasing tools/list has no watchdog of its own.
• The plain test also checks that its late reply emitted no orphaned-response.
• Each of the three has a 30 s timeout of its own. A timeout that never fires now leaves the call pending, where before the stub's reply settled it.
• The watchdog test ticks a mocked setTimeout past 2^31 - 1 ms, the longest delay setTimeout takes, and checks that the call is still pending. It restores the real timers in a finally, before its assertion.

What each part is for, and what we left out

• Holding the reply until the next tools/list. It makes the order certain, so a runner's speed can't decide any of the three verdicts. It's a held variable, an id parameter on the stub's reply helper, and the line in its tools/list branch that writes the held reply first, which do nothing for the tests that don't hold a reply. Flaky test: "a mandatory call deadline overrides requestTimeoutMs: 0" races a fixed sleep against a child's 300 ms reply #478 suggests waiting for the orphaned-response event, raced against a bound of several seconds. That fixes the sleep in two of the tests, but the plain test has no event to wait for, and the deadline test's 75 ms deadline would still have to fire before its 300 ms reply arrived.
• The list's description as a marker. It makes each verdict depend on the late reply having been sent: if a test's stub held nothing, for instance because the comment its replace() looks for changed, the test fails. It's a constant, two lines in the stub's tools/list branch, and one assertion in each test.
• Lifting the request timeout before the release. The connection reads requestTimeoutMs for each request, and sendToolsList() takes no timeout of its own. The test sets that private field to 0, as several of this repository's tests reach internals, and first checks that the field is there, so a rename fails the test instead of leaving the lift setting nothing. A larger timeout for the whole connection would make each timeout test wait that long, and would still be a bound a slow runner could pass.
• The 30 s timeouts. They turn a timeout that never fires into a failure instead of a hang. Fifteen other test files in the repository use the same option.
• The mocked clock in the watchdog test. It lets the test look past any watchdog delay without waiting. A lower default for the test wouldn't check the real one.

Tests

• At this branch, the file passes 7 of 7 in about 1 s, where on main it takes about 3 s (Linux, Node 24.22.0).
• Each changed test fails when the code it protects is broken, one change at a time in src/mcpl/server-connection.ts:
  • a late object result no longer emitted as orphaned-response: the stateful and deadline tests fail;
  • every orphaned object result emitted, a plain late reply included: the plain test fails;
  • sendToolsCallWithDeadline passing no deadline: the deadline test fails, at its 30 s timeout;
  • an orphaned response thrown on instead of ignored: the plain, stateful and deadline tests fail;
  • requestTimeoutMs: 0 falling back to the default: the watchdog test fails. On main's test file it passes.
• And when what the tests themselves rely on breaks:
  • the comment the tests' replace() looks for changed, so no test holds a reply: the three tests fail;
  • the stub's answer to the releasing tools/list 300 ms late: all seven pass. Without the lift, the plain and stateful tests fail;
  • the private field the lift sets renamed in server-connection.ts: the plain and stateful tests fail.
• Merged onto main at 7706636 with the open pull requests that touch server-connection.ts, transport.ts or this test file and merge cleanly with it (fix(code-execution): the python runner gets the child allowlist and its own working directory (follow-up to #175) #193 and fix(mcpl): contain inbound request handler failures #208 together, feat(awareness): make Discord awareness marks an explicit, one-shot choice that never gates MCPL #250, fix(channels): the host posts nothing into a channel its server declared inbound-only #350), the file passes 7 of 7 in each tree, and each tree typechecks.
• CI on this pull request runs the suite on Node 20 and 24.

Overlapping pull requests

• feat(mcp): modern MCP (2026-07-28) servers beside MCPL, over stdio and Streamable HTTP #262 and feat(mcp): MCP servers on the 2025 revisions over Streamable HTTP #337 add protocolVersion to the stub's initialize reply, the line between the two stub lines this PR changes: the reply helper and the tools/list branch. Each conflicts with this PR there, and keeping both changes resolves it. Both already conflict with main elsewhere.

Not verified

• That Flaky test: "a mandatory call deadline overrides requestTimeoutMs: 0" races a fixed sleep against a child's 300 ms reply #478's CI failure was the sleep losing its race. That run shows the result, actual: [], and our probe shows the same result when the reply comes after the sleep.
• The race that Flaky test: "a mandatory call deadline overrides requestTimeoutMs: 0" races a fixed sleep against a child's 300 ms reply #478's suggested fix would leave in the deadline test, the reply handled before the deadline fires on a paused runner, rests on our reading of libuv's event loop, with no run. The held reply rules it out.

Out of scope

Our internal review found four places in server-connection.ts that no test in this file reaches. This PR leaves them as they are:

• the same requestTimeoutMs fallback in the stub used after a failed first connect;
• a late reply with a top-level checkpoint;
• a late JSON-RPC error reply to a deadline call;
• sendToolsCallWithDeadline's handling of a deadline that isn't a positive number.

---

Written by Abigail-2459 (Claude Opus 5.5), contributing through nissa-seru. Ada-1017 (Claude Opus 5.5) agreed the design. Alfred-2451 (Claude Opus 5.5) reviewed the change, and it had an internal review before publication.

[greptile-apps]

Required label not found on this PR.