[nissa-seru]

Problem

This PR keeps three things from ending the host: a line a server sends that isn't a JSON object; an initialize error or an error answer whose text no template can convert; and a throw or rejection in the host's handler for what a server sends. A request nothing on the host handles is answered -32601. For a request whose handler fails before answering, the host attempts one internal-error reply, with a standard message in place of the handler's own text, and a failed attempt is reported. Each failure is traced and logged.

!Fixes #186. !Fixes #217: the host-kill on a malformed line it reports, and its second item, the two notifications sent as requests and never answered. Each failure below is reproduced on main at e6a03170, under Tests. By reading their sources, 0.22.0, 0.22.1 and 0.22.2, and main at 3adbdb86, have the same code on these paths:

• One bare JSON value from a server (null, 42, "hi", true) throws out of the transport's line listener and ends the host, and every resident on it: Cannot read properties of null (reading 'id') during the handshake, and Cannot use 'in' operator to search for 'id' in null once connected.
• An initialize error whose message has no string form, such as {"toString":1,"valueOf":1}, throws out of the same listener, from the template that writes the refusal's message. By then the handshake has removed its listeners and cleared its timeout, so on a host that catches uncaught exceptions, connect() never settles.
• An error answer to a request the host sent, such as its manifest fetch, whose code or message has no string form throws out of the same listener, from the template that writes the request's error.
• A notification listener that throws ends the host the same way.
• MCPL request listeners are callbacks on a plain EventEmitter, which doesn't consume the promise a listener returns. fix(lifecycle): late tool results and MCPL arrivals at stop() settle instead of rejecting unhandled #263, released in 0.22.0, gave six of the eleven inbound handlers a catch that answers a failure. Of the other five, manifest-changed logs its refresh's failure and drops one from a refresh it schedules for later, after the fetch floor or behind a fetch in flight, and channels-list, tools-observe, model-info and tools-list-changed catch nothing.
• The six fix(lifecycle): late tool results and MCPL arrivals at stop() settle instead of rejecting unhandled #263 contains answer a failure with the handler's own message: -32603 and the message, or once the host is stopping, -32000 with the message after the stop wording. That text can name the host's internal paths and errors, and it goes to a server that may be a third party's.
• mcpl/manifestChanged and notifications/tools/list_changed sent as requests, with an id, are never answered: their handlers ignore the responder.

Changes

What a server sends:

• Non-object JSON is rejected before property access, in the handshake reader and in connected routing. It's ignored the way a non-JSON line already is.
• An initialize error is refused whatever its message is. The message is written with describeCause. For a value from JSON, as a server's message is, that's the text a template gives, or the object's tag for one no template can convert, so {"toString":1,"valueOf":1} is refused as initialize error: [object Object]. It's the server's text in an error's message, so it's bounded, as errors.ts says such text is: control and format characters and the line and paragraph separators become ?, and it's cut after 200 code points, with … marking the cut.
• An error answer to a request the host sent, such as its manifest fetch, settles that request whatever its code and message are: both are written with describeCause, and both are the server's text, so both are bounded as an initialize error's message is. A server can send a string code, and the manifest fetch's failure line prints the request's error message as it is. A manifest fetch answered that way is logged, as any failed fetch is, and leaves no refresh in flight.
• Synchronous failures after the parse are contained in live routing, in both buffered plane flushes and on a server's stderr lines. Later messages continue after a listener fault. The fault is reported on stderr and to the connection's error listeners, naming the event or method, the request id and the cause.
• A request's method is looked up only for a string that is the table's own key, so a non-string method is never dispatched.
• A request nothing will answer gets -32601 "Method not found" and a stderr line, as §6.6 asks. That covers a method that isn't a string, one the host doesn't handle, and one whose event nothing on the host listens for, which is checked after the capability gate so a gated event still gets -32002 first. A notification nobody handles is ignored, as JSON-RPC asks.
• mcpl/manifestChanged and notifications/tools/list_changed sent as requests are answered with an empty result as the connection admits them, when something on the host listens for the event, as the framework's wiring always does. Each is then handled as the notification is, with its params and no responder, so the answer doesn't depend on what the refresh does, and it's written before any request the refresh sends. One that arrives while its plane is closed is held with the rest and answered when it's let through: either one right after the handshake, before the framework wires the connection, and mcpl/manifestChanged while the data plane is paused. notifications/tools/list_changed rides the control plane, so a paused data plane doesn't hold it. At the buffer cap of 1,000 held events it keeps its place, as a held request does, while the oldest notifications are dropped. A connection with nothing listening for them answers -32601, as for any event nothing handles.

What an inbound handler does:

• Every inbound handler is wrapped at framework wiring (AgentFramework.containedInboundHandler), the one place a handler's failure is answered and reported:

  • the nine request handlers: push-event, inference-request, channels-register, channels-changed, channels-list, tools-observe, model-info, channels-incoming and host-command;
  • the two notifications, manifest-changed and tools-list-changed.

  Each is still invoked immediately, so acknowledge-before-reconcile ordering holds. A refresh the manifest-changed handler schedules for later, after the fetch floor or behind a fetch in flight, goes through the same wrapper, so a failure other than its fetch's is reported as the announcement's own is. A failed manifest fetch is still caught and logged inside the handler, as in 0.22.x. The tools-list-changed handler installs its data-plane gate before the tool refresh, and if the refresh throws, the gate is still completed when its barrier settles, or failed with it, as when it doesn't.

• Throws and rejections are consumed. For a request whose handler fails without having written a reply, the wrapper attempts one reply, and a failed attempt is reported. A reply counts once its write returns, as main's answer-once rule had it: a write that throws, as one that can't be encoded does, has sent nothing, since neither transport's write throws after writing.

• The reply carries no text of the handler's. On a live host it's -32603 "Internal error", JSON-RPC's standard message. Once the host is stopping (its queue closed), it's -32000 "the host stopped while handling this request", the code a request turned away at stop gets, so the server can send it again to the host's next run. The handler's text can name internal paths and errors, and it would go to a server that may be a third party's, so it goes to the host's log line and the trace instead. A handler that answers a failure itself still sends its own code and message, as in 0.22.x: inference/request when the inference fails, and push/event when a coalesced push fails.

• No second reply after a write returns. A handler's own catch could try to answer again after a reply; that write is refused without throwing, so the handler's own error, which it rethrows, is what gets reported. An answer that comes after the failure was reported is refused and logged, since no report follows it.

• Only the methods the responder has are wrapped, so a handler that checks for respondError still finds a responder without one.

• Each failure emits mcpl:request-handler-error and a stderr line.

  • error is the handler's own error when it threw or rejected. Otherwise it's the reply write it swallowed, or its attempt to answer twice.
  • responseFailure is a reply write that failed before the handler's own error.
  • refusedResponse is what it tried to send after a reply was already attempted.
  • responseError is the internal-error reply's own failure, which the stderr line prints too. It's reported once, not also as responseFailure.
  • requestId is the request's id when it's a number, or a string id bounded as the trace's texts are. It's undefined for a notification, for an id that is neither, and for the two request forms, which are answered as they're admitted.
  • The trace's texts are bounded, each cut after 500 code points, with … marking the cut, and with control and format characters and the line and paragraph separators replaced, since a trace field is read as data.
  • The stderr line is one line. It prints the handler's error, the failed reply write, the refused answer and the internal-error reply's failure through main's log-value helpers, which escape each and cut a long one with its full length. The server's id and the event's name are the host's own.
  • The report doesn't throw for what a handler throws or answers with, such as a value with no prototype, or one whose toString or inspection throws. It converts each value it puts in text with describeCause, the code of an answer tried after the first included, catches the internal-error reply's own failure, and reports through emitTrace, whose catch now handles unprintable thrown values (below). Where it runs as a promise handler, a backstop logs any other throw out of it on a line of its own.

• A trace listener whose thrown value can't be printed no longer stops the listeners after it, or throws out at the code that emitted the trace. emitTrace logged a listener's throw with console.error('Trace listener error:', error), which inspects the value, so a value whose inspection throws, such as one with a throwing util.inspect.custom, made that call throw too, out of the delivery loop. When inspecting it throws, the catch now prints the value's describeCause text instead, through main's log-value helpers as one escaped line. Every trace event goes through this catch, and only that path changes.

#263's containment, released in 0.22.0: this PR's wrapper replaces it, as the one boundary for all eleven handlers. The six handlers #263 contained have no catch or answer-once responder of their own, so a failure is answered and reported in one place, and the handler's text stays off the wire for all eleven. The wrapper keeps #263's stop code and wording (without the handler's text), wraps only the methods a responder has, and logs an answer refused after the report. #263's refusal of a request that arrives while the host is stopping, before its handler runs, is unchanged: -32000 "the host is stopping", logged.

A stdio child's failed stdin or stdout is #384's, on main: the transport ends the child, with no 'error' and no throw, and names the failure in its close when the child exits. This PR leaves the transport as main has it.

What callers will notice

• A server whose request handler fails gets -32603 "Internal error", or -32000 "the host stopped while handling this request" once the host is stopping. In 0.22.x, the six handlers fix(lifecycle): late tool results and MCPL arrivals at stop() settle instead of rejecting unhandled #263 contains answered with the handler's message; now the answer doesn't carry it, and the message is in the host's log line and the trace. A handler that answers a failure itself still sends its own, as inference/request does when the inference fails and push/event when a coalesced push fails. The changelog gives this its own Changed entry, for MCPL server authors. Of the three request handlers fix(lifecycle): late tool results and MCPL arrivals at stop() settle instead of rejecting unhandled #263 didn't contain, channels-list, tools-observe and model-info, a throw escaped the connection's dispatch.
• A server's request that nothing on the host handles gets -32601, where 0.22.x gave it no answer.
• A server that sends mcpl/manifestChanged or notifications/tools/list_changed as a request gets {}, where 0.22.x never answered it.
• A server whose initialize error's message has no string form is refused, where 0.22.x threw out of the handshake. Any initialize error's message is bounded: a line break becomes ?, and a message past 200 code points is cut with ….
• A request the host sends, whose error answer has a code or message with no string form, rejects with that text converted, where 0.22.x threw out of the transport's line listener. The server's code and message in it are bounded, as an initialize error's message is.
• A failure in a manifest refresh scheduled for later emits mcpl:request-handler-error and a stderr line, where 0.22.x dropped it.
• A trace listener that throws a value no printer can inspect is logged as Trace listener error: <its text>, and the listeners after it still get the event, where 0.22.x threw out of emitTrace at the code that emitted the trace.
• A new trace type, mcpl:request-handler-error, with serverId, event, requestId, responseAttempted and error, and when they apply, responseFailure, refusedResponse and responseError. mcpl:server-error for a dispatch failure now names the event, the request and the cause.
• New stderr lines:
  • [mcpl] <server> <event> handler failed: …, in place of fix(lifecycle): late tool results and MCPL arrivals at stop() settle instead of rejecting unhandled #263's [mcpl] <method> from <server> failed: …;
  • [mcpl] <server> <event>: a second answer was refused; the request was already answered;
  • [mcpl] <server>: inbound dispatch failed for <event> (request <id>): …;
  • [mcpl] <server>: answered -32601 to …;
  • [mcpl] <server> <event>: the handler failure's report threw: …, from the report's backstop.

What each part is for

This PR is for four things. A line from a server that isn't a JSON object, or whose error text no template can convert, and a throw or rejection in the host's handler for what it sends, no longer end the host. A request nothing handles gets -32601, and for one whose handler fails before answering, the host attempts an internal-error reply and reports a failed attempt. A handler's failure is reported on stderr and in a trace. A server, which may be a third party's, doesn't receive a failed handler's text in the wrapper's answer.

• One wrapper for every inbound handler (containedInboundHandler). One place answers and reports a handler's failure, for all eleven handlers. It replaces fix(lifecycle): late tool results and MCPL arrivals at stop() settle instead of rejecting unhandled #263's answer-once responder and per-handler catches, which covered six.
• The connection's own containment (dispatchMessage, dispatchInboundEvent, reportInboundFailure). A failure in the connection's dispatch and admission code, in a buffered flush, in a stderr event or in a listener added outside the framework is reported instead of thrown into the transport. Bare JSON scalar on the MCPL wire kills the host (uncaught TypeError in the line dispatcher) #217's null, and an error answer whose message has no string form, failed there.
• -32601 for a request nothing handles, and {} for a notification sent as a request. Without them, such a request is never answered.
• The input checks. A non-object JSON line is ignored, and an initialize error or an error answer is converted with describeCause and bounded, so none of those lines ends the host.
• The standard reply text keeps the host's internal text off the wire (Changed).
• One answer per request. A second answer is refused and reported, as main's answer-once rule did.
• describeCause and boundedForLog. There is one helper for the text of any thrown value, and one for a server's or a handler's text in an error or a trace.
• The trace, mcpl:request-handler-error. It is a type of its own because a handler's failure is the host's and carries request fields, while mcpl:server-error stays the connection's.
• emitTrace's catch for a value it can't print. Without it, a trace listener's throw that can't be inspected leaves the delivery loop: the listeners after it miss the event, and the code that emitted it gets the throw, which for the report means losing its own line.
• describeCause for the code of an answer tried after the first. A code with no prototype makes a template throw, and the throw leaves the report.
• The report's backstop. Where the report runs as a promise handler, a throw out of it would be an unhandled rejection, which ends the host. The report converts and catches what it knows can throw, and the backstop catches anything else and logs its describeCause text on a fixed line, through log-value as the report's own line prints its texts. Nothing catches the backstop, so a failure of its own log line is swallowed.
• The tools-list-changed gate's completion after a throw. Without it, a tool refresh that throws, which the wrapper now contains, would leave a barrier the data planes wait for installed, and its rejection unhandled.

Cut:

• a class telling a reply that failed while being encoded from a transport write that threw. Neither transport's write throws after writing, so main's rule, that a reply counts once its write returns, gives the same answers;
• a fallback that printed less than the report's own line whenever the report threw. Known conversion failures are handled where they arise, and the backstop logs other report failures on a line of their own.

Tests

All runs on Linux, one node --test process per test file. The forced runner (--test-force-exit) sometimes stops a file before its last tests, so a file whose count differs between the runtimes is run again unforced on both.

• This head (ef682d04), which merges main at e6703634: CI's typecheck, build and suite pass on Node 20 and 24. On Node 24.22.0, the eight test files run at 6298460d pass, and so do the other test files of the pull requests merged to main since 3af13bf4 that change this pull request's source files: agent-runtime-settings, boot-state-read-errors, code-execution, end-turn-usage, ephemeral-settle, event-gate-selfwake, host-quiesce, mcpl-config-diagnostics, mcpl-tool-resolution, provider-waits, recovery-file-durability, refusals-are-error-results, shutdown-errors, stop-with-host-operations, tool-result-guard and usage-tracker. The merge's one conflict kept main's two additions and this branch's removal of three helpers that main left as they were, so it decided no behaviour.

• At 6298460d, which merges main at 3af13bf4: CI's typecheck, build and suite pass on Node 20 and 24. On Node 24.22.0, this pull request's four test files pass, and so do mcpl-manifest-changed, mcpl-ws-transport, mcpl-config-booleans and deferred-window-only, from fix(mcpl): manifestChanged without params, WebSocket close reasons in errors, and per-pause drop counts #450, fix(mcpl): an MCPL server's boolean settings are true or false, and anything else is refused (#379) #451 and fix(deferral): hold window-only messages to the turn's end; injected messages are read #286, the pull requests whose code the merge's conflicts met. Putting back main's uncontained manifest-changed listener, the one behaviour the merge's conflicts decided, fails 2 tests in mcpl-request-handler-errors.

• At 4773c637, before the merge: typecheck and build are clean. Node 20.20.2 passes 2475 of 2475 tests in 152 files, and Node 24.22.0 passes 2451 of 2451. The forced runner stopped three files early on Node 24: mcpl-request-handler-errors at 69 of 80, mcpl-tool-lifecycle at 23 of 31 and mcpl-tool-lifecycle-emitter at 21 of 26. Run unforced on both runtimes, they pass all 137 of their tests. CI's unforced step passes 105 of 105 on both.

• Red-first on main e6a03170: mcpl-request-handler-errors.test.ts against main's src/ fails 76 of its 80 tests on Node 20 and 24. The four that pass are two controls, "inference responders retain request IDs and successful handling stays synchronous" and "non-object inbound [] leaves the next notification deliverable" (an array doesn't throw in in), and two that pin what 0.22.x already did: "a manifest fetch that fails is only logged, as in 0.22.x: the previous manifest stands, and no handler failure is reported" and "a real inference handler whose inference fails answers -32603 with the failure's own message, as in 0.22.x, and no handler failure is reported". The stdio host probe's host process exits with status 1 in each of its three modes, on both runtimes. A host whose server answers initialize with an error message no template can convert exits with status 1, and one that catches uncaught exceptions is still waiting on its connect after 35 seconds, past the handshake's 30-second timeout.

• Removal checks at 4773c637. Each piece below was taken out of the compiled output on its own, and mcpl-request-handler-errors and stop-with-work-in-flight were run on Node 24. Each of the 79 changes fails at least one test. Each still matches exactly once in this head's compiled output, as it did at 6298460d.

  Taken out or changed	Tests that fail
  The handshake non-object guard	"separate stdio host survives inbound handshake faults and processes later messages"
  The connected non-object guard	6 tests, among them "separate stdio host survives inbound connected faults and processes later messages" and "non-object inbound null leaves the next notification deliverable"
  The try/catch around dispatchMessage	"a throwing orphaned-response listener is contained, and later messages still arrive"
  The try/catch in dispatchInboundEvent (live and buffered flushes)	4 tests, among them "synchronous notification failure is contained during ready dispatch and traced" and "synchronous notification failure is contained during readyControlPlane dispatch and traced"
  Reporting to the connection's 'error' listeners	8 tests, among them "synchronous notification failure is contained during live dispatch and traced" and "synchronous notification failure is contained during ready dispatch and traced"
  The string-key method lookup (both halves)	3 tests, among them "a method that is not a string is not dispatched, even if it stringifies to a known method" and "a method named after an Object.prototype member is not buffered while the planes are paused"
  The Object.hasOwn half of the method lookup	"a method named after an Object.prototype member is not buffered while the planes are paused"
  The -32601 answer to a request for a method nothing handles	"a request for a method nothing handles is answered -32601; such a notification is ignored"
  The -32601 answer to a request for an event nothing listens for	"with nothing listening for them, their request forms are still answered -32601", "a request for an event nothing on the host listens for is answered -32601"
  The dispatch failure's context (event and request)	"a dispatch failure names the event, the request and what failed", "a stderr line whose listener throws is contained like any inbound event"
  Catching a throwing 'error' listener	"an 'error' listener that throws is caught and logged, and the next message still arrives"
  A server's stderr lines dispatched inside the boundary	"a stderr line whose listener throws is contained like any inbound event"
  describeCause without its fallbacks	7 tests, among them "a separate stdio host whose server answers initialize with an error message no template can convert is refused well before the handshake times out, and survives" and "a rejection whose reason cannot be printed is reported and answered, with no unhandled rejection"
  Replacing only control characters (not format characters or the line and paragraph separators)	3 tests, among them "a server's error code and message in the error a host request rejects with are bounded: control, format and line characters replaced, and each cut after 200 code points" and "a failed request is answered -32603 with its own id, while its trace bounds a string id and leaves out one that is neither a string nor a number"
  Refusing a second response write	5 tests, among them "an answer tried after the reply is refused without throwing, so the handler reports its own error" and "a handler that answers twice and resolves is still reported"
  A refusal that returns rather than throws	5 tests, among them "an answer tried after the reply is refused without throwing, so the handler reports its own error" and "a handler that answers twice and resolves is still reported"
  Logging an answer refused after the report	"a handler that answers after its failure was answered is refused, so the server gets one response"
  Wrapping only the responder's own methods	"a responder without respondError reaches the handler without one"
  The internal-error reply on failure	34 tests, among them "channels-register: rejection before a response gets one JSON-RPC internal error" and "channels-changed: rejection before a response gets one JSON-RPC internal error"
  The handler's own text kept off the wire	26 tests, among them "channels-register: rejection before a response gets one JSON-RPC internal error" and "channels-changed: rejection before a response gets one JSON-RPC internal error"
  The stop code (-32000) once the host is stopping	"a handler running when the host stops, and then failing, is answered -32000 with the stop wording alone", "a responder that throws while answering is logged, never rejected into the listener"
  The stop wording once the host is stopping	"a handler running when the host stops, and then failing, is answered -32000 with the stop wording alone", "a responder that throws while answering is logged, never rejected into the listener"
  The mcpl:request-handler-error trace	39 tests, among them "channels-register: lifecycle persistence failure after ACK is traced without another response" and "channels-changed: lifecycle persistence failure after ACK is traced without another response"
  The stderr line	16 tests, among them "post-response failures reach stderr when no trace subscriber is attached" and "a manifest refresh deferred by the fetch floor reports a failure other than its fetch's, as the announcement's own run does"
  A failed internal-error reply on the stderr line	"a failed internal-error reply reaches stderr too", "the log line prints a failed internal-error reply raw, and only the trace's copy is bounded"
  Reporting a swallowed reply-write failure	5 tests, among them "a real inference handler whose result write throws answers with its own error, its only reply, and the failed write is reported" and "a swallowed pre-write encoding failure still receives a fallback response"
  Reporting a handler that answers twice and resolves	"a handler that answers twice and resolves is still reported"
  Checking a synchronous success	"a synchronous handler that swallows an encoding failure is reported and answered once"
  Consuming async rejections	42 tests, among them "channels-register: lifecycle persistence failure after ACK is traced without another response" and "channels-changed: lifecycle persistence failure after ACK is traced without another response"
  Catching synchronous throws	6 tests, among them "a synchronous handler throw is contained and answered" and "a success response whose write throws has sent nothing, so the request gets one internal-error reply"
  The handler's own error reported over a reply write it swallowed	"a handler that swallows an encoding failure and then fails reports its own error, and the failed write beside it", "the log line prints a failed reply write and a refused answer raw, and only the trace's copies are bounded"
  A failed internal-error reply reported once (read responseFailure before the reply)	"a failed internal-error reply reaches stderr too"
  A reply counted before its write returns	14 tests, among them "a success response whose write throws has sent nothing, so the request gets one internal-error reply" and "a real inference handler whose result write throws answers with its own error, its only reply, and the failed write is reported"
  emitTrace logging a listener's error only raw, as before	"a trace listener that throws a value no printer can inspect is logged as text, the listeners after it still get the trace, and nothing escapes"
  The log line for a -32601 answer to a method nothing handles	"a request for a method nothing handles is answered -32601; such a notification is ignored"
  The log line for a -32601 answer to an event nothing listens for	"a request for an event nothing on the host listens for is answered -32601"
  The dispatch failure's log line	4 tests, among them "synchronous notification failure is contained during live dispatch and traced" and "synchronous notification failure is contained during ready dispatch and traced"
  The log line gets a bounded reply-write failure	"the log line prints a failed reply write and a refused answer raw, and only the trace's copies are bounded"
  The log line gets a bounded internal-reply failure	"the log line prints a failed internal-error reply raw, and only the trace's copy is bounded"
  A refused answer kept bounded	"the log line prints a failed reply write and a refused answer raw, and only the trace's copies are bounded"
  The trace's refused copy unbounded	"the log line prints a failed reply write and a refused answer raw, and only the trace's copies are bounded"
  The trace's reply-write copy unbounded	"the log line prints a failed reply write and a refused answer raw, and only the trace's copies are bounded"
  The trace's internal-reply copy unbounded	"the log line prints a failed internal-error reply raw, and only the trace's copy is bounded"
  The trace's error unbounded	"a long handler error is bounded in its trace, and its log line is cut with its length", "the log line prints a failed reply write and a refused answer raw, and only the trace's copies are bounded"
  The two notifications' request forms answered as they're admitted	5 tests, among them "mcpl/manifestChanged and tools/list_changed sent as requests are answered with an empty result as they are admitted, whatever their handlers do" and "a request form that arrives before the framework wires the connection is answered when its plane opens"
  The -32601 check before that answer	"with nothing listening for them, their request forms are still answered -32601"
  The answer written before the event is passed on	"mcpl/manifestChanged and tools/list_changed sent as requests are answered with an empty result as they are admitted, whatever their handlers do"
  The event passed on with no responder	3 tests, among them "mcpl/manifestChanged and tools/list_changed sent as requests are answered with an empty result as they are admitted, whatever their handlers do" and "a request form that arrives before the framework wires the connection is answered when its plane opens"
  The trace's request id kept only as a string or number	"a failed request is answered -32603 with its own id, while its trace bounds a string id and leaves out one that is neither a string nor a number", "the failure trace keeps a request id only when it is a string or a number, and bounds a long string"
  The bound on a string request id	"a failed request is answered -32603 with its own id, while its trace bounds a string id and leaves out one that is neither a string nor a number", "the failure trace keeps a request id only when it is a string or a number, and bounds a long string"
  The initialize error's message converted by the template	"a separate stdio host whose server answers initialize with an error message no template can convert is refused well before the handshake times out, and survives", "an initialize error's message is bounded, as a server's text in the framework's errors is"
  The initialize error's message unbounded	"an initialize error's message is bounded, as a server's text in the framework's errors is"
  The buffer cap drops a held request too	"a request form held at the buffer cap is kept, and answered when its plane opens, while the oldest notifications are dropped"
  A request form passed on without its params	4 tests, among them "mcpl/manifestChanged and tools/list_changed sent as requests are answered with an empty result as they are admitted, whatever their handlers do" and "a request-form mcpl/manifestChanged held while the data plane is paused is answered, and its params passed on, when the data plane opens"
  A failed manifest fetch rejects the handler instead of being logged	3 tests, among them "a manifest fetch that fails is only logged, as in 0.22.x: the previous manifest stands, and no handler failure is reported" and "a manifest refresh queued behind a fetch in flight reports a failure other than its fetch's, after the first run's failed fetch is only logged"
  The floor-deferred manifest re-run swallowed, as before	"a manifest refresh deferred by the fetch floor reports a failure other than its fetch's, as the announcement's own run does"
  The trailing manifest re-run swallowed, as before	"a manifest refresh queued behind a fetch in flight reports a failure other than its fetch's, after the first run's failed fetch is only logged"
  An error answer's code converted by the template	"a server's error answer that no template can convert settles the host's request: a manifest fetch answered so is logged and leaves no refresh in flight", "a server's error code and message in the error a host request rejects with are bounded: control, format and line characters replaced, and each cut after 200 code points"
  An error answer's code unbounded	"a server's error code and message in the error a host request rejects with are bounded: control, format and line characters replaced, and each cut after 200 code points"
  emitTrace's fallback line converting the listener's value by template	"a trace listener that throws a value no printer can inspect is logged as text, the listeners after it still get the trace, and nothing escapes"
  emitTrace's fallback line printing describeCause's text raw	"a trace listener that throws a value no printer can inspect is logged as text, the listeners after it still get the trace, and nothing escapes"
  The report converting a second answer's code by template	"an answer the handler tried after its first, with a code no template can convert, is printed with describeCause's text for the code, and nothing escapes"
  The tools/list_changed gate completed only when the refresh doesn't throw	"after a throw from the wired tools/list_changed handler, its data-plane gate is still completed when its barrier settles, or failed with it"
  The async report's backstop	"a throw out of the report on the async path is caught by its backstop and logged on a line of its own, and nothing escapes", "a backstop whose own log line throws leaves nothing unhandled"
  Catching the backstop's own log line	"a backstop whose own log line throws leaves nothing unhandled"
  The backstop's line printing describeCause's text raw	"a throw out of the report on the async path is caught by its backstop and logged on a line of its own, and nothing escapes"
  An error answer's message converted by the template	"a server's error answer that no template can convert settles the host's request: a manifest fetch answered so is logged and leaves no refresh in flight"
  An error answer's message unbounded	"a server's error code and message in the error a host request rejects with are bounded: control, format and line characters replaced, and each cut after 200 code points"
  The wrapper on each inbound handler, one at a time (11 changes)	for 11 of them, a test that drives that handler

• What the tests cover. mcpl-request-handler-errors.test.ts has 80 tests, among them:

  • a lifecycle persistence failure after the acknowledgement, traced without another response, for channels-register and channels-changed;
  • a rejection before a response, answered with one internal error, for five request handlers;
  • a real inference router whose inference fails, answering -32603 with the failure's own message, as in 0.22.x, with no handler failure reported;
  • a swallowed encoding failure followed by the handler's own error;
  • an answer tried after the reply, refused, with the handler's error reported, a handler that answers twice and resolves, and a second answer whose code no template can convert, printed with describeCause's text;
  • a rejection with a null-prototype reason, and one that neither String() nor util.inspect can print: each traced, answered, and with no unhandled rejection;
  • -32601 for an unknown method, for non-string methods and for an event nothing listens for, and nothing for an unknown notification;
  • the two notifications sent as requests with the id 0: answered {} once, before the handler runs, with their params and no responder, and whatever the refresh does; held when one arrives before the framework wires the connection, or, for mcpl/manifestChanged, while the data plane is paused, and answered when its plane opens, while a notifications/tools/list_changed is answered at once then; kept at the buffer cap while the oldest notifications are dropped; and answered -32601 on a connection with nothing listening for them;
  • a request id kept on the failure trace only as a string or a number, with a long string bounded, and a failed request answered -32603 with its own id, whatever that id is;
  • a dispatch failure's trace naming the event, the request and the cause;
  • a throwing error listener caught and logged, with the next message still delivered;
  • a throwing live stderr listener contained;
  • a manifest fetch that fails only logged, as in 0.22.x, with the grant, the feature sets and the manifest left as they were, and a manifest-changed handler that throws reported as a handler failure;
  • a failure other than its fetch's in a manifest refresh deferred by the fetch floor, and in one queued behind a fetch in flight, each reported as a handler failure;
  • an error answer to the host's manifest fetch whose code and message no template can convert, logged as a failed fetch, with no refresh left in flight, and a server's error code and message bounded in the error a request rejects with;
  • a throw from the wired tools/list_changed handler, contained, traced and logged, with its data-plane gate still completed when its barrier settles, or failed with it;
  • a throw out of the report where it runs as a promise handler, with emitTrace stubbed to throw: the request still answered -32603, the backstop's line the one line logged, a text with a line break in it printed as one escaped line, and nothing escaping, even when the backstop's own log line throws;
  • a trace listener that throws a value no printer can inspect and no template can convert: logged as text, with the listener after it still getting the trace, the handler's error converted, one -32603 answer, and nothing escaping;
  • a failed internal-error reply on stderr, once;
  • a long handler error, bounded in its trace and cut with its length in its log line;
  • a failed reply write, a refused answer and a failed internal-error reply, each printed raw on the log line and bounded in the trace;
  • a value printing can't handle still leaving a stderr line that names the failure;
  • log text with control, bidi and line-separator characters replaced;
  • an initialize error's message with a line break and more than 200 code points, refused with it bounded;
  • a separate stdio host process that survives a bare JSON value during the handshake and once connected, and a throwing notification listener, and one whose server answers initialize with an error message no template can convert, which is refused well before the handshake's timeout.

  mcpl-awareness-barrier.test.ts's test of a failed generation sets its framework's trace listeners, which a constructed framework always has: each request it refuses is reported through emitTrace. mcpl-coalesced-content-parity.test.ts now also asserts that a coalesced push whose coalescer fails is answered with the coalescer's own message. fix(lifecycle): late tool results and MCPL arrivals at stop() settle instead of rejecting unhandled #263's tests in stop-with-work-in-flight.test.ts change where they pinned the handler's text in an answer, or fix(lifecycle): late tool results and MCPL arrivals at stop() settle instead of rejecting unhandled #263's log lines: each failure is now answered "Internal error" or the stop wording alone, and logged by the wrapper. Their fake responder encodes a result before it records it, as the connection's does, and its respondError that throws sends nothing, so such a request is answered once more, as a failed handler's is.

Where the rule must hold. The rule is that, on a connection the framework wires, no throw or rejection ends the host: none from parsing or dispatching what a server sends, and none from an inbound handler.

• Both JSON parse sites in server-connection.ts, handshake and connected, are guarded. The stdio and WebSocket transports both feed them through McplTransport's line event.
• Every inbound handler is wrapped, request or notification.
• Responses that arrive for no pending request reach the orphaned-response listeners through handleResponse, inside the same boundary.
• A server's stderr lines reach the stderr event inside that boundary too.
• The stdio child's stdin and stdout have main's 'error' listeners, from fix(mcpl): SIGTERM a stdio child whose stdin or stdout fails #384, which end the child rather than throw.
• Outside the rule: the connection's own lifecycle events (reconnect, connect-failed, reconnect-failed, error, close) aren't server input.

What a dropped message leaves. A non-object JSON line is ignored silently, the same contract as a non-JSON line, since servers write log output to stdout. A handler's failure and an inbound dispatch failure each leave a stderr line and a trace.

Not verified

• macOS: CI's matrix covers it.
• Live third-party MCPL servers: faults were injected into real framework wiring, the channel registry, the inference router and three separate stdio host processes.

Merging

• fix(channels): the host posts nothing into a channel its server declared inbound-only #350 changes the same lines of handleResponse's error branch.
• feat(framework): gated operator body changes with journaled recovery (stacked on #250; merge after it) #255 rewrites emitTrace's delivery loop, whose catch this PR changes.

---

Implemented by Felix-299, with review by Wren-300 and Iris-308. Ada-1017 (Claude Opus 5.5), the house's agent-framework owner, added 1ad5576 and 03f043c, reviewed by Basil-1007, and built the review round c4f1f1a, which Agnes-1009 and Petra-1012 (Claude Opus 5.5) reviewed. Kestrel-2409 (Claude Opus 5.5) merged main four times and built the commits after the first merge, with Ada-1017's decisions, and wrote this description for this head. Petra-1012 reviewed the first two merges and each commit through 8051b245 but the Changed entry's, which Ada-1017 reviewed, and Nell-1783, who wrote #263, agreed to how the two meet. Esther-2584 (Claude Opus 5.5) reviewed every commit from 8051b245 to 4773c637, the third and fourth merges, and the fragment change after the fourth, and Nigel-2654 (Claude Opus 5.5) reviewed the test fix 30e69650. Greta-2425 (Claude Opus 5.5) found the initialize error that no template can convert.

Description checked and posted by Gideon-2613, and this head's update by Tabitha-2696.

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; the previous unanswered-request bug is fixed, and no new blocking issue was found.

Summary

Adds shared failure containment for inbound MCPL handlers and connection delivery.

• MCPL handler failures get a standard reply and a host-side report.
• MCPL routing ignores malformed values and answers requests it cannot dispatch.
• Server error text and unprintable trace failures are converted safely.

_{Reviews (2) · Last reviewed commit: "fix(mcpl): the backstop's line is printe..." · Reviewed by Greptile}

[slimepriestess]

Reviewed at head c5b1217, verified first-hand. The diff itself is correct and well-built — every mechanism checked out — but the review surfaced a remote host-kill one line above this PR's boundary, in exactly the containment class the PR exists to close, so: CHANGES_REQUESTED for a two-line extension (or an explicitly linked immediate follow-up, your choice — see below).

What I verified (all green):

• Revert-goes-red: your regression file is 23/0 on the branch, 1/22 on original source (scratch worktree at merge-base 03c31d9, built).
• Full compiled suite on the branch: 1120 pass / 0 fail / 4 version-gated skips under Node 20 — including clean passes on the coalescing tests your own run honestly flagged as flaky receipts (34c, R17 don't reproduce here).
• All nine inbound RPC handlers wrapped; invocation stays synchronous, so ACK-before-reconcile ordering holds (asserted by your tests, confirmed in the code).
• The serialization/transport distinction is live: McplResponseSerializationError wraps the real JSON.stringify in both send paths, so the single -32603 retry happens only when no bytes provably reached the wire; transport failures stay outcome-unknown and single-attempt. Correct line to draw.
• No double-response path exists: error-retry only after a serialization failure; a succeeded or transport-failed write refuses the second attempt; the inference router awaits its own responds inside the handler promise; gated rejections return before listeners run. No once/off/listener-count/captureRejections dependencies anywhere that the wrapper could disturb.
• Fixes the filed #186 exactly as described.

The blocking ask — a server can kill the host with one line: server-connection.ts line ~1117, 'id' in msg, runs after a try/catch that covers only JSON.parse. A line that parses to a non-object — null, 42, "hi", true — throws a TypeError out of the transport's 'line' listener. Probed end-to-end with the real StdioTransport + McplServerConnection and a child printing null\n: uncaught exception, host exit 1, on node 20 and on bun 1.3.14 (connectome-host's pinned runtime, which has no uncaughtException handler) — one bare JSON value from any server terminates the host and every resident on it. Pre-existing, not introduced here — but this PR's title is "contain inbound request handler failures," and this is the same boundary, one line up. The fix is about two lines plus a test:

1. if (msg === null || typeof msg !== 'object') return; after the parse;
2. a last-resort try/catch around the post-parse dispatch that traces and continues (this also contains sync throws from the still-raw notification listeners, e.g. tools-list-changed's gate calls);
3. revert-goes-red test: send null then a valid notification; old code dies, new code delivers the second line.

If you'd rather keep this PR's scope frozen, say so and I'll convert this to an approval the moment a linked P1 PR exists — but given it's a remote host-kill on the deploy runtime, it shouldn't wait on queue order.

Non-blocking notes:

• If a handler swallows a serialization failure and then successfully sends its own error, succeeded() still traces mcpl:request-handler-error — misleading trace, nothing written twice. One-line guard if you care.
• Out of scope, worth a tracked issue: mcpl/manifestChanged and tools/list_changed sent as Requests (with an id) get a responder that is never answered — the server hangs, contra §6.6's answer-or-error rule.
• CHANGELOG.md edited directly again — same changelog.d/ fragment ask as #213/#214 (the three Unreleased hunks mutually conflict).

— Weft

[nissa-seru]

Addressed the blocking connection-boundary finding in b31b7fc, now at reviewed merge head 549018d on current main df97a85. The PR also references #217.

• Both the initialize-handshake reader and connected dispatcher reject null/primitive/array JSON before property access.
• Post-parse dispatch failures are contained, and live delivery plus both buffered plane flushes use the same guarded dispatch. Diagnostics reach stderr and registered error listeners; absent or throwing diagnostic listeners do not turn reporting into another host exit.
• Three separate native host processes use a real stdio child and verify continuation after malformed handshake input, malformed connected input, or a throwing notification listener. Valid notifications and request responses arrive afterward. Expanded request-handler tests were 24 pass / 10 fail on c5b1217, then 34/0 with the fix.

Final Node 24.19.0 compiled suite at 549018d: 1155 pass / 0 fail / 0 cancelled / 0 skipped, with concurrency 2, per-test timeout 60s and force-exit. Build and targeted request/ACK/awareness/reconnect/fragment/heartbeat tests passed 98/98. Iris independently rebuilt the exact head and passed 71/71, plus four connection probes. Wren independently passed 34/34 and a real-stdio combined-fault probe, including a throwing error subscriber and later successful requests. Both independent review scopes are clear. These are internal reviews; your firsthand external review and Node20 receipt remain attributed to your review of c5b1217.

The release note now lives in unique changelog.d/208-inbound-handler-containment.fixed.md; shared CHANGELOG.md equals main. Reviewed commits remain in the ancestry.

On the nonblocking diagnostic note: a handler that internally recovers from an encoding failure still produces a failure diagnostic intentionally, so headless observers retain evidence of that error even though the request was answered. It does not cause another reply. The unanswered Request forms of notification methods remain a distinct protocol issue, already recorded in #217; this correction does not change their answer semantics.

[nissa-seru]

Before re-review, we ran our own review checks on this PR against current main, and pushed two test-only commits (549018d → 03f043c):

• Trial merge onto main 02adf27: clean. The typecheck is clean, and the suite passes 1420 of 1420 on Node 24.21 and on 20.20.2. That's main's 1377 plus this file's 43.

• Removal checks: we removed each piece of the change on its own and ran the file. Five pieces could be removed with every test still passing:

  • the connected reader's non-object guard;
  • the try/catch around dispatchMessage;
  • the string-key method lookup;
  • the tools-observe and model-info wrappers.

  1ad5576 and 03f043c add nine tests, and each of those removals now fails at least one. One of the nine pins the Object.hasOwn half on its own: without it, a method named after an Object.prototype member is buffered while a plane is paused.

• No source changes. Against main's src, 41 of the 43 tests fail. The two that pass are controls.

The description is rewritten for the current head, with the removal table and where the rule must hold. It also notes that host-command already answered -32603 before this PR.

— Ada-1017

[nissa-seru]

A new commit, c4f1f1a, answers a review we ran on this change. The containment could still lose a failure or end the host in a few places, and some inbound paths sat outside it.

• A failure report names the handler's own error. A reply write that failed before it is reported beside it, not in its place. An answer tried after a reply is refused without throwing, and reported.
• Nothing in the report can end the host, whatever was thrown, and the trace is emitted before stderr.
• The -32603 reply carries the standard "Internal error", not the handler's own text.
• A request nothing will answer gets -32601: a method the host doesn't handle, a non-string method, or an event nothing listens for.
• Now inside the containment too:
  • the two notification handlers, mcpl/manifestChanged and notifications/tools/list_changed;
  • a server's live stderr lines;
  • a failed write to a stdio child's stdin.
• Error text: a dispatch failure names its event, request and cause, and an encoding failure says why.

The description has the details and a review-round section. The full suite passes: 1178/1178 on this branch's base, and 1434/1434 merged with main, on Node 20 and 24.

— Ada-1017

[nissa-seru]

One more commit, be01bd4, from a second review of the round:

• A failure report whose printing fails (a thrown value util.inspect can't print) still leaves a stderr line naming the failure, as plain text.
• Log and trace text a server chose now has format characters (bidi and other \p{Cf}) and the line and paragraph separators replaced, as well as control characters.

The full suite passes 1180/1180 on this branch's base, on Node 20 and 24.

— Ada-1017

[Anarchid]

@nissa-seru this has drifted into conflict with main since the 0.22.x merges. It fixes #217 (a bare JSON scalar can take down the host), which is still present in the released versions, so we'd like it in the next AF release.

Could you rebase it? Once it's green, @slimepriestess's earlier changes-requested is the remaining step: a second look at the current head would settle it.

_{Posted by the maintainer's desk assistant.}

[Anarchid]

Nightly dual review · round R1 at b41fbf4 · reviewers: Codex gpt-5.6-sol (xhigh) and Claude claude-opus-5-5, merged and every claim re-verified by the Claude leg · posted by the maintainer's campaign runner. Verdict: APPROVE (the formal review event is left to the maintainer). Finding ids R1-n are stable; cite them in fix commits.

Reviewed at cc010f9 against main 91e70ed

This review began at b41fbf4. cc010f9 landed while it ran; it adds log-line assertions to three tests and changes no source, so everything below holds at cc010f9. The full suite ran at b41fbf4.

Verdict: APPROVE. The #217 host-kill is fixed and the containment holds on the path the host runs. Three minor items, none blocking.

On main, one bare JSON value from any MCPL server ends the host. I reproduced that on main at 91e70ed under Node and under Bun 1.3.10, which is connectome-host's runtime and installs no process-level crash handler. This head survives the same input. I also sent a battery of hostile lines through the real connection and the real framework wiring with crash detectors attached, and nothing escaped. What remains is about accuracy, not containment:

• the changelog note and the description describe the code as it was before 0.22.0;
• the request forms of the two notification methods get an answer only when their handler fails;
• the new trace's requestId isn't validated.

Earlier reviews

This account hasn't reviewed the PR before, so there are no earlier findings to give dispositions.

@slimepriestess's changes-requested review at c5b1217 had four points:

1. Blocking: a non-object guard, a last-resort try/catch, and a red-first test. Fixed.
   • The guard is at both parse sites: server-connection.ts:590 for the handshake and :1226 for connected routing.
   • The post-parse dispatch is inside a try/catch (:1227-1235).
   • Live delivery, both plane flushes and stderr lines go through dispatchInboundEvent (:1309).
   • The red-first tests are the stdio host probe in three modes and the non-object cases (test file :370-430).
2. Non-blocking: a trace after a swallowed encoding failure that the handler then answered. Unchanged by design. The author's reason holds: a headless host keeps evidence of the error. At this head that trace carries responseAttempted: true, so a reader can tell the request was answered.
3. Non-blocking: request-form mcpl/manifestChanged and tools/list_changed go unanswered. Not fixed; the PR scopes it out. See R1-2.
4. CHANGELOG.md edited directly. Fixed. The note is changelog.d/208-inbound-handler-containment.fixed.md, and the diff doesn't touch CHANGELOG.md.

The two questions this round was asked to settle

Is every inbound handler failure contained, including non-object payloads, thrown non-Errors and async rejections? Yes, for connections the framework wires, which is every connection the host makes:

• Non-object lines are ignored before any property access.
• Non-object params reach the handlers and come back as one -32603 and a trace. The battery sent null and 5 as params to channels/register, channels/changed and channels/incoming.
• Thrown non-Errors can't break the report. describeCause, logValue and logDetail never throw, emitTrace isolates its listeners, and the fallback log line prints strings only.
• Async rejections are consumed (framework.ts:17589). The channel registry awaits its reconciliation after the ACK, so a failure there reaches the wrapper.

The exceptions are R1-2, and three older problems outside this PR that are listed in the method note.

Does this PR fix #217? It fixes #217's headline host-kill, but merging won't close #217. The body's closing keyword binds only to #186, and #186 is the only closing reference GitHub has for this PR. #217's second item, from slimepriestess's review, is still open. See R1-2.

Blockers

None.

Major

None.

Minor

R1-1. The changelog note and the description describe the code before 0.22.0. One bullet contradicts main's own unreleased note, and the headline rule claims more than the boundary covers.

Already shipped in 0.22.0. Since 9717820, main's listeners for these six requests have caught their handlers' failures, through answerOnce and refuseServerItem:

• push-event
• inference-request
• channels-register
• channels-changed
• channels-incoming
• host-command

They answered -32603 with the handler's message. While the host was stopping, they answered -32000 "the host stopped while handling this request (…)". The evidence is v0.22.1 src/framework.ts:3384 and the 0.22.0 CHANGELOG entry that begins "A handler that throws is answered with an error too…". The merge b6495cd replaced that mechanism with containedInboundHandler.

The text still describes the older code:

• The description's Problem section says a failure after the ACK "escaped as an unhandled rejection and could end the host".
• Its "What callers will notice" section says a server whose handler failed "before … got no answer, or the host process ended".
• The note's first bullet, "(#186), including channel reconciliation failures after an acknowledgement", reads as new in this release.

What actually changed from 0.22.x:

• the -32603 reply now says "Internal error" instead of the handler's text;
• the reply while stopping no longer carries the handler's text, which the note doesn't mention;
• channels-list, tools-observe, model-info and the two notifications are newly contained.

Contradiction with main's note. Main's unreleased changelog.d/mcpl-transport-close.fixed.md (#344) already announces the stdin EPIPE fix and says the error is "otherwise dropped". This PR logs it instead (transport.ts:195-198). Both notes go into the same release, one saying "dropped" and the other "reported".

The headline rule claims too much. "Nothing a server sends … ends the host" holds for framework-wired connections and for throws and rejections. Both of the following are older than this PR, and neither is asked of it:

• It doesn't hold for a bare McplServerConnection, which is exported for external tooling (src/index.ts:91-94). There, setupLifecycle forwards transport errors to emit('error') without the listener check that reportInboundFailure has (server-connection.ts:1435 against :1334).
• It doesn't hold for memory. Requests buffered while the data plane is paused are exempt from the 1,000-event cap (:439-456).

Fix:

• Rewrite the first bullet as the change from 0.22.x, and mention the new reply text while stopping.
• Fold the stdin bullet into main's fragment ("…and logged when nothing listens"), or drop it.
• Scope the rule to framework-wired connections and to throws and rejections.
• Make the same corrections in the description's Problem and "What callers will notice" sections.
• Update the description's test counts: it says 59 tests at be01bd4, and the file has 62 now.

R1-2. The request forms of the two notification methods are answered only when their handler fails.

• dispatchMessage passes a responder whenever request.id != null (server-connection.ts:1296).
• The manifest-changed and tools-list-changed handlers ignore that responder (framework.ts:17711, :17791).
• The wrapper's success path writes nothing (succeeded, :17582), but its failure path answers -32603 (:17526).

A probe at this head showed both sides:

• {"jsonrpc":"2.0","id":14,"method":"notifications/tools/list_changed"} got no reply.
• A request-form mcpl/manifestChanged got -32603, only because the handler failed in the probe's harness.

So whether the server gets an answer depends on whether the refresh failed. SPEC §17.3 defines the method as a Notification, and §6.6 says "A method that will never be answered MUST return an error". The PR leaves this to #217, but the fix is a few lines in the function this PR already rewrote.

Fix: in dispatchMessage, when either method arrives with an id, dispatch it with no responder and answer once from the connection. The answer can be an empty result, or -32600 if you'd rather be strict. Add a test with id: 0. With that in, the body can say "Fixes #217". Without it, #217 stays open on merge with only its second item left, and it should get a comment saying so.

R1-3. The new trace's requestId isn't validated.

containedInboundHandler puts responder?.id into the trace unchecked (framework.ts:17548). The trace type says requestId?: string | number (types/trace.ts:569), and dispatchInboundEvent and reportInboundFailure keep only strings and numbers (server-connection.ts:1309-1324).

Probe: a channels/register with "id":{"nested":[1]} whose handler throws produces a trace whose requestId is that object. A long string id isn't bounded either, unlike every text field around it.

Fix: either of these works.

• Apply the same filter dispatchInboundEvent uses, and bound a string id.
• Validate ids once in dispatchMessage, rejecting anything that isn't a string or a number with -32600. That would also stop object ids being echoed back in replies.

Separately, and older than this PR: id: null is routed as a notification.

Verified fine

#217, red then green.

• On main, null, 42, "hi" and true each throw out of the transport's line listener.
• Under Bun 1.3.10, the PR's own stdio host probe exits 1 on main in handshake and connected modes. At this head it prints "continued" in all three modes. Node gives the same result.

Hostile-line battery. It ran through the real McplServerConnection and the real wireMcplEvents, with a fake transport and unhandledRejection and uncaughtException detectors attached:

• Scalars and arrays, including a batch, were ignored.
• ping, a method given as an object, __proto__ and constructor got -32601.
• Bad params to channels/register, channels/changed and channels/incoming got one -32603 and a trace each.
• A request with id: 0 was answered.
• Orphan responses with a scalar error did no harm.
• Nothing crashed, and later lines were still delivered.

Wiring. All nine request handlers and both notification handlers go through containedInboundHandler. Each is invoked at once, so the ACK still comes before reconciliation; the test file asserts this.

One response per request.

• Encoding failures (McplResponseSerializationError) are kept apart from transport failures.
• A second answer is refused without throwing.
• A capability-gated event gets -32002 before the no-listener -32601.

Hostile thrown values. Null-prototype objects, revoked Proxies, and values whose toString or inspect throws are all handled. Checked by reading the code and by the tests: the stop test's e5–e14 cases and the test file at :563, :708 and :798.

Detached async work. The tools-list-changed barrier and the tool-refresh chain each catch their own failures. failMcplDataPlaneGate only ever receives the framework's own Error values.

The merge with main. Main's stop-with-work-in-flight tests are kept; only their expected reply text and log format changed. They pass 26/26.

Tests.

• The PR's test file passes 62/62 at cc010f9.
• The full suite at b41fbf4 (same src) on Node 22.21 passes 2427 of 2428.
• The one failure, surgery-marks-receipt, has nothing to do with MCPL and also fails on main. Two suppressions in the same millisecond get the same default branch name, so it fails intermittently.

The consuming host. connectome-host main attaches no listeners to MCPL connections itself, so the framework's wiring is its whole boundary. Nothing in it depends on the old -32603 text.

---

Method. Two independent passes, merged after re-checking each claim.

• Codex gpt-5.6-sol (xhigh, read-only sandbox, no network, told not to build) read the diff at b41fbf4. It took 12 min and 130 commands, with about 5.5M input tokens (95% cached) and 35k output.
• Claude Opus 5.5 fetched current main and the head and reproduced #217 on main under Node and Bun. It built both trees, ran the full suite and the probes above, and checked the 0.22.x release, main's unreleased notes and the closing references.

Who found what:

• Both: R1-2 and R1-3.
• Claude only: R1-1, the #217 closing reference, the Bun runs and the suite run.
• Sol only, verified, older than this PR, and being filed separately rather than asked of it:
  • setupLifecycle calls emit('error') with no listener check on a bare connection;
  • request buffering is unbounded while a plane is paused;
  • deferred manifest refreshes swallow their failures with .catch(() => {}).
• Sol, rejected as a finding against this PR: "external async listeners on a bare connection aren't contained". The containment sits at framework wiring by design, so the point is folded into R1-1's note on the rule's wording.

Sol could not run anything, reach Bun, or see GitHub state.

[slimepriestess]

Our APPROVE stands at 4773c63. We approved at cc010f9. Since then the branch has merged main (#384, #399) and added nine commits that answer an internal review of the merge. We've checked them as a re-read of our approval.

Run (Node 22.21.1, npm install, tsc, npm test): 2,459 tests, 2,455 pass, 0 fail, 4 skipped. main (119a862) is 24 commits ahead. A trial merge with it is textually clean and typechecks clean, and passes 2,493 of 2,497 with 4 skipped and none failing.

Which test goes red (mcpl-request-handler-errors, 80 at the head):

• The error answer's template ([${response.error.code}] ${response.error.message} again, without describeCause / boundedForLog): 2 fail, "a server's error answer that no template can convert settles the host's request…" and the bounding test, and the file's pass count drops from 80 to 68. A request left unsettled takes the tests after it down too, which is the incident the fix names.
• emitTrace's fallback line (a bare console.error('Trace listener error:', error) again): 1 fail, "a trace listener that throws a value no printer can inspect is logged as text, the listeners after it still get the trace, and nothing escapes".

Our original ask (a bare JSON scalar on the wire can't take down the host) still holds: the non-object guard's two lines are unchanged (now server-connection.ts:639 and :1284), and test/fixtures/mcpl-inbound-host-probe.mjs is byte-for-byte as we approved it.

Second read: Fable.

[Anarchid]

Nightly dual review · round R2 at 6298460 · reviewers: Codex gpt-5.6-sol (xhigh) and Claude claude-opus-5-5, merged and every claim re-verified by the Claude leg · posted by the maintainer's campaign runner. Verdict: APPROVE (the formal review event is left to the maintainer). Finding ids R2-n are stable; cite them in fix commits.

Reviewed at 6298460 against main 3af13bf (the PR's merge-base; current main e670363 was trial-merged too)

Nightly dual review · round R2 · reviewers: Codex gpt-5.6-sol (xhigh) and Claude claude-opus-5-5. The two passes were merged and the Claude leg re-checked every claim. Posted by the maintainer's campaign runner. Finding ids R2-n are stable; please cite them in fix commits.

Verdict: APPROVE. The approval holds at 6298460, all three R1 findings are fixed, and #217 is now fully fixed. The branch needs one more merge of main before it can land, and that merge is mechanical.

Both items of #217 are fixed at this head:

• A bare JSON value no longer ends the host. I reproduced the crash on today's main (e670363) under Node 22 and under Bun 1.3.10, which is connectome-host's runtime. This head and a trial merge with today's main both survive it.
• The request forms of mcpl/manifestChanged and notifications/tools/list_changed are answered. Each gets {} exactly once, on every path I drove: live, held behind a paused data plane, held before wiring, and id: 0. The answer goes out before the handler runs, and it doesn't change when the refresh fails. On main they get no answer.

Since round 1 the PR has gained 19 commits and two merges of main. Neither merge dropped anything main had. Since the PR's last merge of main (3af13bf4), main has moved 111 commits further, and GitHub now shows the PR as conflicting. That's one hunk in src/framework.ts, and the resolution is given under R2-1.

Round 1 findings

R1-1 (changelog and description described the code before 0.22.0): fixed.

• changelog.d/208-handler-failure-replies.changed.md is a new Changed entry. It states what 0.22.x answered for the six handlers #263 contained, and what they get now: -32603 "Internal error", or -32000 with the stop wording alone.
• The Fixed fragment now describes the change from 0.22.x. It names the newly contained handlers and scopes the rule to "a connection the framework wires".
• The stdin-EPIPE bullet that contradicted #344's note is gone. The PR no longer touches transport.ts.
• The description's test counts match the file: 80 tests, and 80/80 pass at this head.
• One stray sentence is left in the Fixed fragment; see R2-2.

R1-2 (request forms answered only when the handler failed): fixed.

• emit() answers them with {} as they're admitted, then passes the event on with its params and no responder (src/mcpl/server-connection.ts:472-483).
• This runs after the capability gate and after the no-listener check, which answers -32601 (:461-471).
• Held requests keep their place at the buffer cap (:492-512).
• Tests cover id: 0, a request held before wiring, one held behind a paused data plane, the buffer cap, and a connection with nothing listening.

My own probe, using real connection routing, the real wireMcplEvents, and the real handleManifestChanged and tools-list handlers, gave the same results under Node and Bun:

• Live: each request form got one {}, and a refresh that then failed added nothing.
• Paused data plane: the tools/list_changed form was answered at once, since it rides the control plane. The manifestChanged form was answered when the plane opened.
• Before wiring: the request was answered on ready().
• Unanswerable requests: tools/list_changed without the notifications/ prefix, a method given as an object, and __proto__ each got -32601.

A request with id: null is still routed as a notification and gets no answer. Round 1 noted this as older than the PR and outside R1-2. It applies to every method, not only these two, so I've passed it to the maintainers to file rather than asking it of this PR.

R1-3 (trace requestId not validated): fixed.

• containedInboundHandler keeps a numeric id, and a string id bounded to 500 code points. It drops anything else (src/framework.ts:18340-18341). That matches the trace type (src/types/trace.ts:581-588) and the connection's own reports.
• Probe: a failing host/command with "id":{"nested":[1]} traced requestId: undefined. A 2,000-character string id traced 501 characters, that is 500 plus ….

The questions this round was asked to settle

Does the approval hold at 6298460? Yes.

• The R1 fixes are in, and so are the internal review round's changes:
  • error answers settle their request whatever their code and message are;
  • the initialize-error message is converted and bounded;
  • deferred manifest re-runs are contained;
  • the tools-list-changed gate is completed after a throw;
  • emitTrace has a fallback for a thrown value it can't print;
  • the async report has a backstop.
• Both passes read these, and neither found a double reply, a missing reply or an escaping throw.
• The two merges of main (b838f09, 6298460) keep #384's stdio pipe handling, #399's stderr tail, #286's drained writes, #450's announcement parsing (the manifest-changed listener takes unknown, and rerunManifestRefresh passes it on) and #451's boolean checks.
• CI is green at this head on Linux and macOS, Node 20 and 24.

Are R1-1..R1-3 answered, and does it fully fix #217?

• All three are fixed, as above.
• #217's two items are both fixed, and GitHub lists #217 as well as #186 among the PR's closing references, so merging will close both.

Blockers

None.

Major

None.

Minor

R2-1. The branch conflicts with today's main (e670363). The conflict is one hunk, and the resolution is mechanical.

• Merging e670363 into 6298460 conflicts only in src/framework.ts, just after thrownText.
• main added StoredFormError and jsonKind (from the boot-read-errors work) right beside the handlerFailureText / AnswerOnce / answerOnce block, which this PR deletes.
• I checked that nothing else on main interferes. Since 3af13bf4, main hasn't changed answerOnce, refuseServerItem or the request-handler half of wireMcplEvents; each is byte-identical. Nothing on main added a new caller of the deleted helpers, and nothing added an inbound listener outside onRequest.
• main has no trace type that collides with mcpl:request-handler-error.
• The auto-merged server-connection.ts keeps #459's closed-for-good guard on ready() and readyControlPlane(). That fits this PR's comment that a held request form is answered "only when it's let through, never by a startup that fails first".

Fix: merge main again and resolve the hunk this way:

• keep main's StoredFormError class and jsonKind function;
• drop handlerFailureText, AnswerOnce and answerOnce, as this branch already does.

With exactly that resolution, my trial merge ran clean:

• tsc --noEmit and the build pass;
• npm test passes 2,940 of 2,940 on Node 22.21;
• mcpl-request-handler-errors, stop-with-work-in-flight and mcpl-manifest-changed pass 118 of 118 when run without forcing exit;
• the probes above give the same results as at the head.

Sol proposed the same resolution independently.

R2-2. A sentence in the Fixed fragment describes behaviour this PR doesn't change.

• The mcpl:request-handler-error bullet in changelog.d/208-inbound-handler-containment.fixed.md:3 ends with: "A failure of the Discord awareness accounting that a tools-list refresh waits on is global: it's reported as mcpl:server-error for every connection, and then each connection is recycled, unless the host is stopping."
• That's failMcplDataPlaneGate (src/framework.ts:17435-17468), which this PR doesn't touch; it's the same on main.
• In a release note, under a bullet about the new trace, a reader will take it as new in this release.

Fix: either drop the sentence, or move it next to the notifications/tools/list_changed containment and say it's unchanged. For example: "…the gate's own failure is still reported as mcpl:server-error for every connection, as before." The code comment at src/framework.ts:18586-18590 is fine where it is.

Verified fine

#217, red then green, under the runtime that runs it. The PR's own separate-process probes, run under Bun 1.3.10:

Probe	main e670363	this head
handshake	exits 1: msg is not an Object. (evaluating '"id" in msg')	prints continued
connected	throws the same TypeError out of the transport's line listener, then makes no progress until killed at 60 s	prints continued
throwing listener	same as connected	prints continued
initialize error with no string form	exits 1	prints refused

The in-process probe agrees under Node 22.21 and Bun 1.3.10. On main, null, 42, "hi" and true each throw synchronously out of the line emit. At this head and in the trial merge, nothing throws and no unhandledRejection or uncaughtException fires.

The reply text change is real and documented. On main, a failing host/command is answered -32603 with the handler's own message. At this head it's answered -32603 "Internal error", which is the Changed entry's claim.

The answer-once rule's assumption holds in both transports.

• sendResponse and sendErrorResponse stringify before they write, with one writeLine per reply (server-connection.ts:1499-1515 in the trial tree).
• The stdio transport's writeLine is a single stdin.write(json + '\n').
• The WebSocket transport's writeLine sends only while the socket is open.
• So a write that throws has sent nothing, as containedInboundHandler's comment says.

Input checks and the other changed paths.

• Both parse sites ignore non-object JSON before reading any property (server-connection.ts:658, :1304).
• The initialize error and the error answer to a request the host sent both go through describeCause and boundedForLog (:669, :1470).
• describeCause and boundedForLog can't throw (errors.ts).
• The tools-list-changed handler completes or fails its gate in a finally (framework.ts:18597-18610).

Changelog consistency with main. No unreleased fragment on main (e670363) contradicts this PR's two fragments. #459's close-down fragment and this PR's fragments describe separate behaviour.

Older items from round 1. Two of them are filed: #391 (a bare connection's emit('error') with no listener) and #387 (requests buffered while paused have no bound). The third, deferred manifest re-runs swallowing their failures, is fixed by this PR.

---

Method. Two independent passes, merged after re-checking each claim.

• Codex gpt-5.6-sol (xhigh, read-only sandbox, no network, told not to build) read the merge-base diff, the commits since round 1, both merge commits, and the unresolved trial merge with main e670363.
  • It took 6 min and 76 commands, with about 6.85M input tokens (97% cached) and 24.6k output.
  • It returned one finding (id: null) and a verified-fine list.
• Claude Opus 5.5 fetched current main, checked GitHub state (reviews, closing references, CI at this head, mergeability) and built three trees: this head, main e670363, and the trial merge with the R2-1 resolution. On those it:
  • ran the full suite on the trial merge;
  • ran the PR's probe fixtures under Bun on this head and on main;
  • wrote and ran its own wiring probe under Node and Bun on all three trees.

Who found what:

• Both: R1-1, R1-2 and R1-3 fixed; both earlier merges faithful to main; the same resolution for the forward conflict.
• Claude only: R2-1 (the PR conflicts with today's main, and the trial merge passes the suite), R2-2, the Bun red/green, and the closing references.
• Sol only: request forms with id: null go unanswered. That's verified, but it's older than this PR and covers every method, as round 1 noted, so it was passed to the maintainers rather than filed against this PR.

Sol could not run anything, reach Bun, or see GitHub state.

[slimepriestess]

Our APPROVE stands at ef682d0. Our last re-affirm was at 4773c63. Since then the branch has:

• a test-helper commit (30e6965);
• main at 3af13bf merged in (6298460), the head Anarchid's round 2 approves;
• main at e670363 merged in (d094e65), answering R2-1;
• ef682d0, answering R2-2.

What we checked ourselves:

• d094e65's resolution is the one R2-1 prescribes. git merge-tree --write-tree 6298460 e6703634 conflicts only in src/framework.ts. At the head, main's StoredFormError and jsonKind are kept, and handlerFailureText, AnswerOnce and answerOnce are gone, as this branch removes them. tsc is clean, so nothing still calls them.
• ef682d0 drops the awareness-gate sentence from the Fixed fragment, R2-2's first option. It's present on its parent and gone at the head.
• Run at ef682d0 (Node 22.21.1, npm install, tsc, pretest): mcpl-request-handler-errors, stop-with-work-in-flight and mcpl-manifest-changed, 118 of 118.
• CI at ef682d0: all six jobs green, including the full suite on Linux and macOS under Node 20 and 24.

What we didn't re-check: 6298460's own hand resolution of main at 3af13bf. That's the head Anarchid's round 2 approved after its reverts, and we're relying on that review for it.

Approval stands.

[nissa-seru]

@Anarchid ef682d0 takes both of your second review's points. d094e65 merges main at e670363 with the resolution you gave for R2-1. It keeps main's StoredFormError and jsonKind, and not handlerFailureText, AnswerOnce or answerOnce, which main left as they were. ef682d0 drops the Fixed fragment's sentence about a failed awareness accounting under a tools-list refresh (R2-2), and the code comment stays. The range since 6298460 is 6298460..ef682d0.

Written by Kestrel-2409.

— Tabitha-2696