[nissa-seru]

stop() now sets reconnectEnabled to false on every MCPL connection, in either engine, in the step after endConnectsInFlight, and aborts a legacy-engine reconnect attempt already under way. Both engines check that flag before they schedule or start a reconnect attempt (cited under Changes). In this change's tests, a stdio server lost just before or during a stop, in either engine, isn't launched again while stop() waits, and a legacy WebSocket server whose retry is waiting on its access provider isn't dialed again. Before, a server with reconnect: true lost that way kept its scheduled retry. When stop() waited long enough, 8 s in the probe under Problem, its command was started afresh and reconnected, and it was gone once stop() returned. A relaunch runs whatever the server does before it serves: discord-mcpl's main, for instance, connects to Discord and waits for its ready event before it serves stdio (src/index.ts:48–49 and :119 at its main, 833444a).

Problem

At e85c57db9a, stop() calls stopOwned (src/framework.ts:4875), and the comment at stopOwned's first step reads "No MCP server is admitted from here on (stopHasBegun): none is launched or dialed while the rest are being closed" (:5009–5010). That step calls endConnectsInFlight (:5015), whose loop is over this.mcpServerOps entries of kind connect (:4929–4945). A connection's own retry timer isn't one of those: the legacy engine's is set in scheduleReconnect (src/mcpl/server-connection.ts:1987), and the modern engine's in its own (src/mcpl/modern-connection.ts:904).

A probe ran agent-framework at e85c57db9a, and the published 0.28.0 installed from npm, on Linux with Node 24.22.1. Their dependencies installed at the same versions for every package both have: chronicle 0.4.0, context-manager 0.23.1, membrane 0.8.0, @modelcontextprotocol/client 2.4.0, chokidar 4.0.3, discord.js 14.27.0 and ws 8.22.0. In each engine, one stdio server with reconnect: true was connected, its child got SIGTERM, and stop() was called 20 ms later, held open by a model stream for a set time:

• Not held, or held 2 s, at the default retry interval: one launch, in both engines and both builds.
• Held 8 s at the default interval: the server was launched again and reconnected while stop() waited, 4.1 to 6.3 s after the loss, in both engines and both builds. The legacy engine logged [mcpl] channels/register from discord refused: the host is stopping each time.
• At a 200 ms interval, with a child that takes 3 s to serve: held 2 s, the server was launched again and that child was gone before it served; held 8 s, it was launched again once, served, and reconnected 3.2 to 3.5 s after the loss.

In every case, no child was alive 1.5 s after stop() returned.

Changes

• McplServerConnection.stopReconnecting() (src/mcpl/server-connection.ts:738–741) sets reconnectEnabled to false and aborts a reconnect attempt under way with the abort close() uses. It closes nothing.
• ModernMcpConnection.stopReconnecting() (src/mcpl/modern-connection.ts:527–529) sets reconnectEnabled to false, and closes nothing.
• Both methods' doc comments mark them @internal, "For the framework's stop(); not a host API."
• A new step in stopOwned, right after the endConnectsInFlight step, calls stopReconnecting() on every connection in the legacy registry and every modern connection (src/framework.ts:5016–5022).
• What reads the flag: the legacy scheduleReconnect and attemptReconnect each return when reconnectEnabled is false (src/mcpl/server-connection.ts:2002, :2030). The modern ones each return unless willReconnect, which reads reconnectEnabled (src/mcpl/modern-connection.ts:913, :921, :519–521).
• Five test files' stand-in connections and registries gain stopReconnecting() or getAllServers(), which stop() now calls.
• What it leaves: a modern attempt already under way when stop() begins isn't aborted, since the modern stopReconnecting() only sets reconnectEnabled to false. A reader's probe under Tests shows such an attempt reconnecting during the stop.
• Changelog fragment: changelog.d/mcpl-no-reconnect-after-stop.fixed.md.

With #844

@tel-0s's draft #844 at 17087e27fb already conflicts with e85c57db9a in 18 files, by git merge-tree. This commit adds a conflict in one more, test/stop-with-host-operations.test.ts: #844 removes the test "stop() waits for a resume past its commit point: it completes, its durable clear lands, and its data plane opens", and this commit adds stopReconnecting(): void {} to that test's stand-in connection. Among the other pull requests open at 11:29Z on Oct 28, this commit adds no conflict.

Tests

At this head, on Linux with Node 24.22.1:

• The suite: npm run clean and npm run build succeed, and npm test gives 8,795 tests: 8,733 passed, 0 failed and 62 skipped.
• test/mcpl-no-reconnect-after-stop.test.ts has two tests:
  • in both engines, with reconnect at a 50 ms interval and a model stream holding stop() for 300 ms, a server whose child gets SIGTERM before stop() begins, or after it has begun, or whose every launch fails, launches no child while stop() waits and traces no mcpl:server-reconnected. A shell in front of each server records each launch as it spawns, and the launches running right after the call to stop() are counted with those recorded before it, so a launch spawned just before stop() whose shell records it late isn't counted as one during the stop;
  • a legacy WebSocket server whose retry is waiting on its access provider when stop() begins doesn't dial when the provider answers.
• Breaks: taking out the new step in stopOwned fails both tests, and so does taking out the legacy stopReconnecting(). Taking out the legacy abort alone fails the access-provider test, and taking out the legacy flag alone, or the modern stopReconnecting(), fails the stop test.

That run didn't record its installed versions. One at aa0cb37dae, an earlier version of this change that differs from this head only by the two @internal doc comments, did: agent-framework commits no lockfile at its root, and npm ls --depth=0 after its install printed chronicle 0.4.0, context-manager 0.23.1, mcpl-core 0.4.0, membrane 0.8.0, @modelcontextprotocol/client and @modelcontextprotocol/server 2.4.0, chokidar 4.0.3, discord.js 14.27.0, ws 8.22.0, tsx 4.23.15 and typescript 7.0.2. There, on Linux with Node 24.22.1, the suite and the breaks gave the same results, and:

• Time: run alone three times after that install, the test file took 4.0 to 5.0 s, with a one-minute load of 12 just before the first. About 2.1 s of each is its seven held stops, each released after 300 ms.

These runs didn't record their installed versions either:

• Red first: in five runs of the new test file at e85c57db9a, both tests failed each time. Every stop case launched a child during the stop: a lost server once more, reconnecting in 16 of those 20 cases, and a server failing since its start five or six more times. The WebSocket server was dialed a second time and reconnected.
• An attempt already under way when stop() begins, from a reader's probe at an earlier version of this change whose src/ differs from this head's only by the two doc comments, with a second launch that waits 2 s before it serves: the legacy attempt was aborted and didn't reconnect, and the modern one reconnected during the stop. In both engines no launch was alive once stop() settled.

Not verified

• A modern HTTP server wasn't run during a stop, neither a redial nor an attempt under way when stop() begins.
• A real discord-mcpl wasn't run: the probe and tests use stand-in servers.

---

• Changelog fragment added: changelog.d/mcpl-no-reconnect-after-stop.fixed.md.

Amos-2081 made the change. Naomi-2422 read it and ran earlier versions of it, and Alfred-2451 weighed an earlier version's parts against the smallest change that would do. Lottie-2661 wrote this description.