[nissa-seru]

This makes the test "a server that dies by SIGTERM while the host is writing to it raises no alert, though the host's write failed, in either engine" put its two events in order itself: the host's write to the child fails first, and only then does the test send the child SIGTERM. Its new title names that order. Before, each child killed itself as the host wrote to it, which left that order to the host's event loop. In CI at #884's head, which merges main at 0f11975e48, the test failed in its modern case. With this change, the test passed in each of 20 runs, and a red run shows it still fails when the transport alerts on such a close. The change is to test/mcpl-down-for-good.test.ts only.

Problem

The test came with #876. It needs the host to record its failed write before it handles the child's exit. At 0f11975e48, src/mcpl/transport.ts:413 gives the close's reason as `child process exited, and its pipe failed with ${this.pipeError.message}` only when this.pipeError is set, and 'child process exited' otherwise.

At 0f11975e48, the legacy child killed itself once its burst of pings was out, and the modern child as soon as its stdin brought data. In CI run 40826523575, at #884's head a3f568c96b, the Build & Test (ubuntu-latest, node 22.12.0) job failed this test. Its modern case read writeFailed: false, with signal: 'SIGTERM', alerts: 0 and posted: 0, and its legacy case read writeFailed: true. a3f568c96b doesn't change this test's file. In src/mcpl/transport.ts it has the pipe-failure wait take its grace from exitGrace(), which returns testExitGraces.get(this.child) ?? STDIO_EXIT_GRACE_MS, and this test file doesn't call setStdioExitGraceForTests, which sets testExitGraces. In a run at 0f11975e48 with the modern child's SIGTERM delayed 300 ms after its first stdin data, the test failed with the same reading.

Changes

• Both engines' children now use the file's DEAF_ON_USR1, which the test "a connected server whose child the transport ends after a pipe failure is said to the operator once, though it dies by SIGTERM, in either engine" already uses. On SIGUSR1 that child runs closeSync(0) and openSync("/dev/null", "r"), writes deaf to stderr, and writes a ping request to stdout.
• The test sends the child SIGUSR1 and waits for its deaf line, which the child writes after closeSync(0). In the modern case it then makes one tool call, for the reason the comment above DEAF_ON_USR1 gives: "A modern host drops the ping, so the test calls a tool instead." It waits until a new helper, pipeFailureOf(), reads the transport's recorded pipeFailure, and only then sends the child SIGTERM.
• pipeFailureOf() reads pipeFailure from the legacy connection's transport, or from the modern connection's session's stdio.
• The test's title is now "a server whose child dies by SIGTERM after the host's write to it failed raises no alert, in either engine".
• The test's comment says that the close names the pipe only if the host has its write's failure before it handles the child's exit, and that the exit must then be handled within STDIO_EXIT_GRACE_MS of the failure, or the transport ends the child itself and the close raises an alert.
• DIES_WHILE_WRITTEN_TO, the two children that killed themselves, is removed. The test's assertions are unchanged: in both engines, signal: 'SIGTERM', writeFailed: true, and no alert.

On October 29 at 06:20 UTC, no open pull request changes test/mcpl-down-for-good.test.ts.

Tests

At a clean checkout of eb88f49c69, on Linux with Node 24.22.1 and npm 11.19.1, after npm install with package-lock.json and node_modules removed, npm run build and npm run pretest, with a one-minute load average of 11.5 at the start and 14.7 after the 20 runs below. npm ls --depth=0 gives @animalabs/chronicle 0.5.0, @animalabs/context-manager 0.24.1, @animalabs/mcpl-core 0.4.0, @animalabs/membrane 0.8.0, @babel/parser 7.29.11, @modelcontextprotocol/client 2.4.0, @modelcontextprotocol/server 2.4.0, @types/node 22.20.5, @types/ws 8.18.2, chokidar 4.0.3, discord.js 14.27.0, tsx 4.23.15, typescript 7.0.2 and ws 8.22.0.

• test/mcpl-down-for-good.test.ts: 20 of 20 pass.
• This test alone, 20 times: it passed each time.
• Red, with src/mcpl/transport.ts:414 reading ...(this.pipeError ? { pipeFailed: true } : {}) in place of ...(this.endedForPipe ? { pipeFailed: true } : {}): the test fails, reading writeFailed: true, alerts: 1 and posted: 1 in both engines.

On GitHub-hosted runners at Node 22.12.0, in a workflow outside this repository, with 3 CPU-burning processes beside the test on macOS and 2 on Ubuntu, this test alone passed 20 of 20 times on macOS and on Ubuntu with an earlier version of this change, whose test file differs from this head's only in comments and the test's title. At 0f11975e48 it also passed 20 of 20 on both. So these runs show that version holding under that load, and don't show 0f11975e48 failing.

Not verified

• The time the test leaves to the transport. When the pipe error comes, src/mcpl/transport.ts:395 at 0f11975e48 calls this.exitWithin(STDIO_EXIT_GRACE_MS), and :565 sets that to 2,000 ms. The test sends its SIGTERM after it has polled for the recorded pipe failure. No run here measured how much of those 2 s the poll, the SIGTERM and the host's handling of the exit take, or slowed them past it. The red run shows that a close marked pipeFailed fails the test with alerts: 1.
• 0f11975e48 failing under load alone. No run showed it fail without the delay above. The CI failure was at a3f568c96b, not at 0f11975e48.
• This repository's CI hasn't run this change.

---

• This change is test-only: it touches nothing in src/, and the no-changelog label applies.

Amos-2081 made the change. Alfred-2451 ran the delayed run at 0f11975e48, and Alfred-2451 and Amos-2081 found that the failing case was the modern one. Naomi-2422 read the change. Daniel-2612 reported the failure in #884's CI, ran this change's tests at a clean checkout and wrote this description.