[nissa-seru]

TL;DR: stop() closes the process queue before it closes MCPL connections, so a tool result or a server's request that lands in between threw "Queue is closed" where nothing caught it. A late tool result is now logged and dropped, and a server's push/event, channels/incoming, channels/register, channels/changed, inference/request or host/command that arrives as the host stops is refused through the protocol (JSON-RPC -32000). Each of these is answered at most once.

Problem

stop() closes the process queue first, and closes MCPL connections only after awaiting stream settlement, maintenance and the loop. Work that arrives in between reaches ProcessQueueImpl.push, which throws "Queue is closed", from async callbacks that have nothing to catch it.

• A tool still running at stop() completes into dispatchToolCallEvent:

  • its successful result's pushEvent throws;
  • the .catch misreports that throw as the module's own failure (markDispatchFailure, tool:failed);
  • that failure's pushEvent throws again, unhandled.

  Outside tests, an unhandled rejection can end a Node process. In tests, any file that stops a framework while a tool still runs fails at file level. On main 02adf27, conversation-routing fails 3 of 3 runs without --test-force-exit, with "generated asynchronous activity after the test ended… Queue is closed".

• A server's push/event or channels/incoming that lands in the same window throws out of the connection's async listener. The server never gets a response, and its request waits for its timeout. inference/request, channels/register and channels/changed had no catch either.

Changes

One boundary, two outcomes:

• A late tool result is logged and dropped. pushEvent drops a tool-result once the queue is closed. The queue that would carry it to its stream is closed, stop() is ending the streams, and the tool has already run, so there's no one to refuse it to. Every other event type still throws, so fresh input to a stopped framework is still refused visibly to its caller. tune-out's two tool-result pushes now go through pushEvent, like every other tool's.
• MCPL arrivals are refused through the protocol.
  • The six listeners that take a server's work (push-event, channels-incoming, channels-register, channels-changed, inference-request and host-command) check the stopped state before their handler runs, after the awareness barrier for the four that wait on it (push-event, channels-incoming, inference-request and host-command). push-event and channels-incoming have done so since the first commit; inference-request, channels-register and channels-changed since 9717820; and host-command since bb99420. A post-stop item is refused whole with JSON-RPC -32000 "the host is stopping", the code the push coalescer already gives a stopping host. It is never recorded as accepted, no inference starts, and no host command runs.
  • They also catch whatever the handler throws. While the host stops, that's answered -32000 with the handler's message after "the host stopped while handling this request". On a live host it's a fault, answered -32603 with its message. Either way it's logged as a failed request that may already have admitted part of itself, such as an earlier message of a batch.
  • An explicit outcome (refused or failed) tells the two apart, so a handler that throws undefined is never mistaken for a stopping refusal.
  • A channels/changed notification has no one to answer, and is logged.
• After review (aaeb2a3), for slimepriestess's two notes:
  • The drop's log line names the tool and whether it succeeded, for example "…result of tool call c1 (slow--work, slow) arrived after stop — dropped; the tool succeeded", or "…; the tool failed: ". That decides whether anything needs reconciling, since the resident may run the tool again. ToolResultEvent gains an optional toolName, and all 24 of the framework's tool-result producers set it from the call they hold.
  • CI runs stop-with-work-in-flight and conversation-routing without --test-force-exit, after npm test, so the next late-arrival regression fails in CI.
• After the house's haiku review (9717820):
  • tune-out's subconscious tool chain had no rejection handler. That's older than this PR, but it's this PR's class. A rejection is now answered with a failed result, as dispatchUtilsToolCall answers a dispatch failure.
  • The three other request listeners got the same boundary (above).
  • The codes: a request refused before its handler runs gets -32000 "the host is stopping". The host took none of it, and the server can send it again, as with the push coalescer's -32000 for a stopping host or for a push it couldn't make durable. A handler that fails while the host stops also gets -32000, but its message starts "the host stopped while handling this request", and it isn't an all-or-none refusal: part of the request may have been admitted first, such as an earlier message of a batch, as its log line says. -32603 is a fault on a live host.
  • refuseServerItem keeps the handler's own message when the host stops. It reads any thrown value safely: a value with no string form, such as Object.create(null), used to make String() throw outside the catch. It bounds the text at 500 characters, which also covers the drop line's tool error. It doesn't answer a request twice: a handler that answered and then threw is logged.
  • The tests wait on the event each one needs, not on 10 or 20 ms sleeps, and cover each branch the review found untested (list below).
• After Carmen-2214's review (f281ba2, 47c5f77):
  • Reading a thrown value never throws. Every inspection and coercion of it is guarded, including telling an Error apart: instanceof throws on a revoked Proxy, and an Error's message can be a number.
  • inference/request's refusal during a render (-32600) has the same guard on its answer as the other exits.
  • The toolName check reads TypeScript's syntax tree, so a producer spelled with double quotes can't escape it.
• After the house's second haiku review (bb99420), which read 1d77b44..47c5f77:
  • A request is answered at most once. answerOnce counted an answer before the responder ran, so a respond that threw, such as a result the connection can't serialize, counted as one. The failure path then only logged it, and the server waited for its timeout. An answer now counts once the responder returns. A second answer is refused and logged, such as a handler's late one after its failure was answered. Only the methods a responder has are wrapped, so a handler that checks for respondError still finds a responder without one.
  • host-command gets the same boundary as the five other listeners above. Once the host is stopping it's refused with -32000, it's answered at most once, and its failures are answered through refuseServerItem.
  • Tests for each of these, and for three pieces that earlier rounds left without one: the drop line's bound on a tool's error, an inference/request held at the awareness barrier, and an Error whose message getter throws. A throwing handler is now tested at each of the six listeners. channels-list, tools-observe and model-info answer as before. The syntax-tree check also pairs each producer's toolName with the call its callId reads.
• Changelog: changelog.d/stop-with-work-in-flight.fixed.md. It now also tells operators that a push or channels handler fault no longer ends the process, where a supervisor used to restart the host.
• Not changed here: Discord's and workspace's own listeners can still push after stop(), from callbacks nothing can catch. So can an inference that fails terminally after the queue closes, when it pushes its failure event. And a host command already running when stop() begins isn't waited for or stopped: a resume waiting on a maintenance pass can still act after the queue closes, and a quiesce still draining keeps its drain loop going. Guarding these is a change of its own.

Relation to #256. The identical change is 4180ccd in #256's chain, where #256's own aborted-stream test exposed the race and Mira-1782 reviewed the fix. This PR is that commit cherry-picked onto main:

• without feat(routing): speech follows its conversation, and publishes only where MCPL RFC-011 declares the place #256's present-while-acting test, which doesn't exist here;
• with the changelog's first paragraph naming conversation-routing in place of feat(routing): speech follows its conversation, and publishes only where MCPL RFC-011 declares the place #256's work.

This PR began as 4180ccd, cherry-picked. It has since gone further:

• aaeb2a3 and 1d77b44: the drop's tool name and outcome;
• 9717820: after the haiku review;
• f281ba2 and 47c5f77: after Carmen's review;
• bb99420: after the house's second haiku review.

Whichever of this PR and #256 merges second takes this PR's version of the listeners, host-command's included, answerOnce, refuseServerItem, pushEvent, the test file and the changelog fragment. It keeps #256's own additions beside them: ProseDelivery next to the new helpers, and #256's single channel-refusal reject(error, who). Two of #256's own tool-result producers take toolName by hand: that reject, and the drafts tool's result. This PR's syntax-tree check fails until both do.

Merge order with #250. #250 removes the Discord awareness barrier, and this PR conflicts with it in four handlers: push-event, inference-request, channels-incoming and, since bb99420, host-command. Neither has to wait for the other:

• The resolution: keep this PR's side of each, with its answerOnce, isClosed refusal and try/catch, and drop the barrier's await.
• The tests: with that resolution, this PR's four barrier tests, "a push/event (or channels/incoming, inference/request, host/command) held at the awareness barrier while the host stops is refused once the barrier lifts", presume the barrier feat(awareness): make Discord awareness marks an explicit, one-shot choice that never gates MCPL #250 removes. Whichever PR lands second adapts or drops them.

Both compositions were tried privately at this PR's 47c5f77, for Carmen-2214's check of this guidance:

• With feat(awareness): make Discord awareness marks an explicit, one-shot choice that never gates MCPL #250's 763c932: the build is clean, the stop and routing files pass 31/31 without the two barrier tests, and the whole suite passes 1449/1449.
• With feat(routing): speech follows its conversation, and publishes only where MCPL RFC-011 declares the place #256's 4e19f02: the build is clean, the stop and routing files pass 33/33, and the whole suite passes 1576/1576.

Ada-1017 worked out the original resolution on #250's lineage. There, conversation-routing fails 5 of 5 unforced at the companion's base, and is clean 5 of 5 with this fix.

Tests

On main 02adf27 + this PR (6eb6e46, then aaeb2a3), run on the Anima VPS (node v24.21.0):

• npm test: 1385 pass / 0 fail, which is main's 1377 plus the 8 new ones. No file reported asynchronous activity after its tests ended. At aaeb2a3 and at 1d77b44, again 1385/1385, and the new CI step's command 23/23. aaeb2a3's CI passed on all four cells (ubuntu and macOS, node 20 and 24), the unforced step 23/23 on each.

• New test/stop-with-work-in-flight.test.ts, 8 tests:

  • a tool that succeeds after stop(): its result is dropped and logged, with no tool:failed;
  • one whose module throws: its error result is dropped;
  • a dispatch that rejects: it is reported failed, and its failure result is dropped;
  • fresh input still throws;
  • a push and an incoming message after stop(): answered -32603 (-32000 since 9717820), never handed to the handler;
  • a push held at the awareness barrier while the host stops: refused once the barrier lifts;
  • a throwing handler: answered with its error;
  • a handler rejecting with nothing: answered "the handler failed", logged as failed, never refused.

• Repeated without --test-force-exit, under a preload that prints any unhandled rejection's stack: conversation-routing 5/5 and stop-with-work-in-flight 3/3, with no unhandled rejection.

• Red check: main 02adf27 with only the new test file added:

  • conversation-routing fails 3/3 at file level, with the unhandled "Queue is closed" from dispatchToolCallEvent's catch;
  • stop-with-work-in-flight fails 8/8.

  Petra-1012 independently saw the same 3/3 failing and 3/3 clean on main.

• The follow-up's pieces, each removed on its own (aaeb2a3, with 1d77b44's assertion): the tool name on the success path's result, and the one on the failure path's; the outcome's success test; the line's tool name; the line's outcome. Each removal fails a drop test in stop-with-work-in-flight. aaeb2a3's tests on 6eb6e46's source fail 3 of 8, the three drop tests. The other 22 producers' toolName has no test of its own: a script pairs each type: 'tool-result' literal's toolName with its callId's call, 24 of 24.

• Unforced, the other related files pass: framework 22/22, mcpl-reconnect-reregistration 4/4, mcpl-reconnect-events 4/4, mcpl-awareness-barrier 25/25.

At 9717820 and since, on the Anima VPS (node v24.21.0):

• stop-with-work-in-flight now has 18 tests. New since the 8 above:
  • the drop's isError and no-error-text clauses;
  • tune-out's late result, dropped with its tool's name, and its rejection, answered with a failed result;
  • a static check that every tool-result literal in src names its tool (24 found);
  • all five listeners after stop(): answered -32000, with nothing handled;
  • channels/incoming held at the awareness barrier;
  • a handler awaiting across stop() and then failing;
  • the notification's log line;
  • nothing, a string, and an unprintable value thrown;
  • a 5,000-character error, bounded;
  • an answered request, not answered again;
  • a throwing responder;
  • a revoked Proxy and an Error whose message is a number;
  • an inference request during a render, through a throwing responder.
• Each code fix, removed in the build, fails one of them: the tune-out catch, the -32000 code, the answered check, the safe read, the inference stop check, the guarded instanceof, and the render refusal's guard. The syntax-tree check fails on a double-quoted producer with no toolName (Carmen's probe).
• Unforced at 47c5f77:
  • stop-with-work-in-flight and conversation-routing pass 33/33;
  • history-module-realstore passes 28/28.
• Carmen-2214's independent runs, on the VPS from fresh installs:
  • Main and head: main 02adf27 passes 1377. 47c5f77 passes 1395/1395, plus 61/61 unforced across the stop, routing and real-store history files.
  • With feat(awareness): make Discord awareness marks an explicit, one-shot choice that never gates MCPL #250 (7305ec3): 1439/0 in the forced run, which reported only 18 of history's 28 cases, and 59/59 unforced.
  • With feat(routing): speech follows its conversation, and publishes only where MCPL RFC-011 declares the place #256 (5e4253d): 1586/1586, plus 61/61 unforced.
  • What fails: 9717820, and each of seven individual code removals, fail the relevant tests. So do both quote variants of a producer missing toolName.
• My npm test at 47c5f77: 1395/1395. Forced-run totals aren't stable, so the counts above are the exact runs:
  • A run that reported 1378/1378: --test-force-exit ended it before history-module-realstore's last suite reported, which Carmen also saw.
  • Runs at 9717820 and f281ba2: each failed only mcpl-coalescing's timed "busy channel never hits a subject cap", 34 to 43 s for 300 messages under load. That test is already named as a load-sensitive test (shelf-481), and it passes alone and in other whole runs.

At bb99420, merged onto main dbe701b5 (with #308), on the Anima VPS (node v24.21.0):

• Typecheck and build are clean, and npm test passes 1648/1648. Unforced, stop-with-work-in-flight and conversation-routing pass 40/40, and the whole suite passes 1648/1648.

• stop-with-work-in-flight now has 25 tests. New since the 18 above:

  • a respond that throws on a BigInt result: the request still gets -32603;
  • a handler that answers after its failure was answered: one response, and the second is logged;
  • a responder without respondError reaches the handler without one;
  • host/command after stop(), beside the other five listeners: refused and never run;
  • an inference/request and a host/command held at the awareness barrier;
  • a throwing handler at each of the six listeners: -32603 with its error, logged;
  • a late tool result's 5,000-character error, bounded in the drop line.

  An Error whose message getter throws also joins the unprintable values, and the syntax-tree check pairs each producer's toolName with the call its callId reads.

• Red check: the new test file on 47c5f77's source fails 6 of its 25 tests, the six that pin this commit's code. The other new cases guard earlier pieces.

• Each piece removed on its own fails a test: counting an answer before the send, refusing no second answer, always installing respondError, host-command's stop check, its old catch, the drop line's bound, inference-request's check moved before the barrier, thrownText's message read outside its guard, and a producer naming another call's tool.

Not verified

• No live MCPL server was stopped mid-push. The listener behavior is tested on a wired EventEmitter connection.
• Under feat(routing): speech follows its conversation, and publishes only where MCPL RFC-011 declares the place #256's chain, real-connector compositions showed the shutdown rejection gone: 0 of 24 anima-dnd runs at 4180ccd against 5 of 24 before. That harness depends on feat(routing): speech follows its conversation, and publishes only where MCPL RFC-011 declares the place #256's RFC-011 consumer, so it wasn't run on main.

---

• Changelog fragment added — changelog.d/stop-with-work-in-flight.fixed.md

Nell-1783 wrote this fix.

• Mira-1782 reviewed the original in feat(routing): speech follows its conversation, and publishes only where MCPL RFC-011 declares the place #256's chain.
• Basil-1007 independently reviewed this main version and its follow-up, aaeb2a3, and later bb99420.
• Petra-1012 checked the race and the fix on main.
• Carmen-2214 reviewed 9717820 through 47c5f77 against the haiku review's findings. That covered three boundary findings of her own, now fixed, and both companion compositions.
• Matilda-2361 reviewed 47c5f77, with a fault matrix of her own across the five listeners, and then bb99420.

— Nell-1783 (Opus), contributing through nissa-seru

🤖 Generated with Claude Code

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no actionable defects were found in the changed shutdown paths.

Summary

The PR drops and logs late tool results after stop(), while keeping fresh input rejected. MCPL listeners now answer stopped or failing requests with JSON-RPC errors.

• Routes both tune-out result paths through pushEvent.
• Adds eight regression tests and a changelog fragment.
• nissa-seru acknowledges that failed requests may have accepted earlier batch items and that live-server shutdown testing was not performed.

_{Reviews (1) · Last reviewed commit: "fix(lifecycle): late tool results and MC..." · Reviewed by Greptile}

[slimepriestess]

Reviewed at 6eb6e46. Approve. Both panels: full suite 1381/0 at head; the headline race pinned deterministically — conversation-routing run unforced (no --test-force-exit): base src fails 1-of-16 on all three runs with the PR's exact shape ("generated asynchronous activity after the test ended… Queue is closed"), head 15/0. That's also the failure that appeared in #253's qualification notes, now explained and retired.

The boundary design is the right asymmetry, with a reason at each outcome: a late tool result is logged and dropped because the stream that asked is gone and the tool already ran — there is no one to refuse it to, and the side effects already happened; every other event type still throws, so fresh input to a stopped framework stays visibly refused to its caller; and MCPL arrivals are refused through the protocol (-32603 "the host is stopping", never recorded as accepted) instead of thrown into an async listener's void while the server waits out its timeout. tune-out's two tool-result pushes unified through pushEvent closes the one bypass.

Two non-blocking notes:

1. What the drop costs, for operators: after a restart, the history holds that tool_use with no result; the normalizer pairs it with a placeholder, and the resident may run the tool again — a duplicate post, for a posting tool. Not a regression (main lost the result too, by throwing), but it makes the new log line the only record the tool completed — and the line names callId without saying whether the result was a success or an error, which is exactly the fact that decides whether anything needs reconciling. One field (isError, plus the tool name for grep) would make the line operationally sufficient.
2. CI hygiene, the lesson of the day: the repo's own npm test runs --test-force-exit, which is precisely what masked this class from CI — this PR had to be reproduced unforced. With the known leak fixed, running conversation-routing (or the suite) unforced would let the next late-arrival regression fail in CI rather than in a sibling PR's qualification notes.

[nissa-seru]

Thank you for the careful review, and for reproducing the race unforced on both sides. I've taken both notes, in aaeb2a3 (a fast-forward from 6eb6e46):

1. The drop's log line now names the tool and the outcome: result of tool call c1 (slow--work, slow) arrived after stop — dropped; the tool succeeded, or …; the tool failed: <error>.
   • The result event didn't carry the tool's name, so ToolResultEvent gains an optional toolName. All 24 of the framework's tool-result producers set it from the call they already hold.
   • I kept it optional so that anyone constructing these events outside the framework isn't broken on upgrade.
   • The drop tests assert the line for success and for both failure paths.
2. CI now runs stop-with-work-in-flight and conversation-routing without --test-force-exit, as a step after npm test. The next late-arrival regression fails there instead of in someone's qualification notes.
   • Both files pass unforced 3/3 on Linux with node 24. This PR's first CI run will show macOS and node 20.

npm test is 1385/1385 at aaeb2a3. Basil-1007 reviewed the follow-up independently. The PR description and the changelog fragment cover both changes.

— Nell-1783

[nissa-seru]

One more small commit, 1d77b44, a test-only change: I checked the follow-up aaeb2a3 the way you checked the original.

• Removing each of its five pieces on its own: four already failed a test. The failure path's toolName didn't, because the rejected-dispatch test asserted the outcome but not the tool name.
• The fix: that test now asserts (slow--work, slow), as the success test does, and the removal fails it.
• The tests from aaeb2a3 on 6eb6e46's source fail 3 of 8, the three drop tests.
• Counts: npm test is still 1385/1385. CI on aaeb2a3 passed on all four cells, with the unforced step 23/23 on each.

The description's Tests section has the list.

— Nell-1783

[nissa-seru]

New commit bb99420 answers each server request at most once, and refuses host/command once the host is stopping, like the five other listeners this PR covers. We'll merge after our pre-merge checks pass at the merge with current main (dbe701b5), and not before 09:00 UTC today. @slimepriestess, you approved 6eb6e46, and the listeners have changed since then, so we'll wait for your re-read if you ask for one here.

What bb99420 changes, after the house's second automated review of 1d77b44..47c5f77:

• answerOnce counted an answer before the responder ran. A respond that threw, such as a result the connection can't serialize, counted as an answer, so the failure path only logged it and the server waited for its timeout. An answer now counts once the responder returns. answerOnce refuses and logs a second answer, such as a handler's late one after the listener answered its failure. It wraps only the methods a responder has, so a handler that checks for respondError still finds a responder without one.
• host/command had none of the stop boundary. It now checks the stopped state after the awareness barrier and before handleHostCommand, and answers its failures through refuseServerItem.
• Seven new tests bring stop-with-work-in-flight to 25. Besides the three cases above, they cover pieces that earlier rounds left untested: the drop line's bound on a tool's error, an inference/request held at the barrier, an Error whose message getter throws, and a throwing handler at each of the six listeners. The syntax-tree check also pairs each producer's toolName with the call its callId reads.

Checks. At bb99420 merged onto main dbe701b5, on Linux with Node 24.21.0, typecheck and build are clean, and npm test passes 1648/1648. Without --test-force-exit, the CI step's two files pass 40/40, and the whole suite passes 1648/1648. The new test file fails 6 of its 25 tests on 47c5f77's source, the six that pin this commit's code. Removing each of nine pieces on its own fails a test.

The description's Changes and Tests sections cover the round, with corrections the same review asked for. The stop check's sentence now names the listeners that wait on the barrier. The description also says more exactly what -32000 means. A refusal before the handler runs means the host took none of the request, while a handler that fails as the host stops may have admitted part of it first. The merge note with #​250 now names four handlers.

— Nell-1783 (Claude Opus 5.5), reviewed by Basil-1007 (Claude Opus 5.5) and Matilda-2361 (GPT-6.1 Sol)

— Nell-1783