[nissa-seru]

Problem

An MCPL server that reconnects has its channel registration refused. A reconnect resets the server's grant, since a fresh initialize starts a fresh §5.3 policy epoch. A chat bridge sends channels/register right after initialize, before the host's new policy Request is answered. The reconnect closed only the data plane, so the registration reached admission at once, was refused against the empty grant (-32002, "initial policy not yet established (§5.3)"), and was never replayed. The route's incoming messages were then unknown channels until the server happened to register again.

Holding the control plane at the connection isn't enough on its own. Every gate's completion readies every connection: startup's staged open, a quiesce resume, an awareness sync, and another server's list change or reconnect. So a gate that completes while a reconnect's exchange is in flight opens that connection's planes before its grant exists. That holds for the data plane today too. With no awareness work pending, another server's tools/list_changed completes its gate as it releases it. At main, the test "another server's list change during a reconnect's exchange doesn't open it either" fails because that list change opens the reconnecting connection's planes before its grant exists.

What changes

• A reconnect closes both planes when it adopts its new transport, as initial connect does. The framework's listener re-establishes the grant and then opens them.
• A policy exchange is marked in flight for the transport it runs on (mcplPolicyExchanges): a reconnect's from its reconnect event, and a connect's from its registration, through a runtime connect's awareness accounting. The registry runs the connect's callback just before it registers the connection (addServer's onRegister). The gate's release and completion pass a marked connection by (mcplPlanesMayOpen). If the gate the connect or reconnect installed was replaced during the exchange, the connection is opened once the exchange settles, as far as the current gate and quiesce allow (openMcplPlanesAfterExchange), and a connection whose transport dropped meanwhile is readied as any gate readies one. A runtime connect runs its exchange only on the transport it registered: if a reconnect replaced that transport during its awareness accounting, the reconnect's exchange covers the new one.
• At a transport boundary, held incoming messages and pushes are kept for the next transport's grant, since a bridge that recorded them as forwarded won't send them again. A kept request doesn't count against Requests buffered while an MCPL data plane is paused have no bound #387's budget of 10,000 held requests, which is for requests a live server waits on: kept requests have a bound of their own, the same 10,000, past which one is dropped and logged. While no transport serves, they stay held even when a gate readies the connection; the host's own reports, such as a stub's connect-failed, go on. The other messages the server sent that are still held, such as its requests, a tools/observe filter or a channel registration, speak for its own process and are dropped and logged; the next process announces its own. The host's own reports about the server, such as its stderr or a connect-failed, stay. A message read from the transport after its close gets the same rule, as a stdio server's can be, since its transport closes on the child's exit while its stdout may still be open: an incoming message or push is held as kept, and any other request or notification is dropped and logged. It's read until a reconnect attempt, if one comes, closes the old reader, so no transport serves while it can arrive. A response read then is matched against none of the connection's requests, since the close ended every one it could answer and the next transport numbers its own afresh, and goes the way of any late answer, as on main: a stateful one is surfaced as an orphaned response, which waits, as the host's other reports do, for the control plane to open. A connection closed for good as its transport closes, by the host's close of a live connection or a drop with reconnect off, has no next transport, so it drops and logs the incoming messages and pushes it holds then, and every request or notification it reads late.
• A message sent again beside a kept copy: a bridge that writes a message and exits before recording it as forwarded sends it again after reconnecting. By our reading, an ordinary incoming message is then admitted twice, since the channel registry keeps no record of message ids outside coalescing. An ordinary push sent again with its eventId is refused as a duplicate while the push handler still holds that id (it holds up to 1,000, and clears when full), and a coalesced message or push gets its first receipt. By our reading of its source, discord-mcpl records a message as forwarded before it writes it, so it doesn't send one again.
• A flush admits the next transport's channel registrations ahead of what a boundary kept, unless one names a channel that an earlier removal, or an earlier registration kept in place, also names. It stops at a boundary crossed during the flush and leaves the rest to the boundary rule.
• An answer is bound to the transport its request came on, and is never written to the next one. So is a streamed inference's chunk: the request's responder carries a chunk sender bound to that transport, which the inference router uses.
• A policy answer that arrives after its transport closed grants nothing, and a request that a close ended is logged as ended by the close, not as unanswered. The same holds for the policy negotiated after a manifest change, a manifest fetched from a transport that has closed isn't installed, and a refresh queued on such a transport isn't run on the next one. A queued refresh's receipt reports the domains of the announcements it coalesced on its transport, each once. The refresh limiter is kept per connection, so a connection that replaces a removed server under its id starts its own, and the removed connection's timers leave it alone.
• Announcements: a connection is announced (mcpl:server-reconnected, module:added) only while the transport its exchange ran on still serves, checked when the announcement is made: for a reconnect after any awareness drain, for a runtime connect after its gate's flush, and for a staged connect once its exchange settles, before startup's gate. A reconnect is announced once its attempt has settled, granted or not, as the changelog has said since 0.22.1, and whether its own gate completed or a newer gate replaced it. For a host that lists modules from the trace, a server whose first connect failed is added (module:added) once, by the first reconnect that's still connected once its attempt settles, granted or not, rather than also when startup or a runtime connect registers it, and one that never connects isn't added.

Why each part is here

The change adds about 185 lines of code to server-connection.ts, about 115 to framework.ts and two to server-registry.ts, and changes seven in inference-router.ts, beside their comments. It's agent-framework #250's reconnect fixes, split out so the fix reaches hosts whether or not #250 is ready, and built on main's awareness gate, which #250 removes.

• Both planes closed at a reconnect is two lines, and it's the fix itself: initial connect already held both planes until the grant existed.
• The exchange marker is one map, one predicate asked by the gate's two loops, and a wrapper around the policy step (settlePolicyExchange). Without it, the next gate to complete undoes the connection's hold. It's feat(awareness): make Discord awareness marks an explicit, one-shot choice that never gates MCPL #250's marker, which feat(awareness): make Discord awareness marks an explicit, one-shot choice that never gates MCPL #250's reviews read, with its check in one predicate (mcplPlanesMayOpen).
• The step after a replaced gate is about ten lines. A gate that completed while the connection was marked passed it by, and without this step nothing would open the connection again. It opens only the control plane while a gate holds data or the host is quiesced, as the gate it replaced would have. It runs whether or not the transport still serves, since a gate readies a connection between transports so that its own reports go on.
• Marking a connect at its registration is one optional callback on addServer, which runs just before the registry registers the connection, so no gate ever sees it unmarked. A mark set when the connect's await resumed would leave a microtask in which a gate's queued completion could open it. The mark covers a runtime connect's awareness accounting, which on main runs before its exchange with the connection already registered. Each way out lifts it, after the close where there is one: a failed accounting before its gate fails, a connect that a stop or a disconnect displaced after its removal, a runtime connect's failed exchange after its close for good, and a staged connect's failed exchange with no close, as on main. A runtime connect whose registered transport closed or was replaced runs no exchange, and logs that, and its mark, naming that transport, no longer matches the connection.
• Running a runtime connect's exchange only on the transport it registered is an option on settlePolicyExchange and the epoch the registration records, about six lines. Without it, a reconnect during a runtime connect's awareness accounting brings two exchanges on one transport, which share one marker, and the server is announced twice.
• The boundary's keep and drop is about 30 lines. Once a reconnect holds control traffic, a transport that drops during its exchange would leave its registration and filter held, to be admitted under the next transport's grant, as held data already was on main. Its requests can't be answered to the process that asked, and its announcements describe a process that is gone, so the boundary drops them. Incoming messages and pushes report the world, and a bridge that records them as forwarded before it writes them, as discord-mcpl does with its watermark, doesn't send them again, so they're kept. A connection closed for good has no next transport whose grant could admit them, so it drops and logs them, where it would otherwise hold them undelivered and unlogged.
• Counting kept requests apart from the held-request budget is about 45 lines. The budget refuses a request rather than dropping it because its server waits on the answer and can send it again. A kept request's server is gone, and its answer is bound to a transport that has closed. Counted against the budget, 10,000 of them would refuse the next process's channels/register, which a reconnect now holds, and every kept message for that channel would then be refused as unknown at the flush. So kept requests have their own count and bound, held both where a request is held and where boundaries with no flush between them join, keeping the earliest; the notification cap counts only notifications; and a flush that holds a kept item again keeps it marked.
• Holding kept messages while no transport serves is about six lines in the flush. A gate readies a disconnected connection, as main does, so that a stub's own reports reach their listeners. Without this hold, what the boundary kept would meet the empty grant then.
• The admission order is about 35 lines. Dropping the dead process's registration means the next process registers that channel again, behind what was kept. A kept message admitted first would be refused as an unknown channel and lost. The channel-order rules keep each channel's writes in the order they were sent.
• Stopping a flush at a boundary is four lines. A listener that closes the connection partway through a flush would otherwise admit the rest of the dead transport's snapshot under the next grant.
• Binding an answer to its transport is about 20 lines. A new process numbers its requests afresh, so an answer written to it for the old process's request could be read as the answer to one of its own with the same id. The tests' fixture sends its registration as id 100 every time.
• Sending a stream's chunks through its responder is a sender in each request's responder, which the router uses in place of its lookup of the server by id, about ten lines across the connection, the handler and the router. A stream that outlives its transport would otherwise send its later chunks to the next process, under an id that process may be using.
• Giving a line read after its transport's close the boundary's rule is about 25 lines: the line handler passes its transport's epoch to the dispatch, which flags a late response for handleResponse and sends a late request or notification to one method (afterBoundary) before anything else reads it, and that applies the rule, holding through emit's buffering, which moves into hold with a kept flag. Node's docs say a child's stdio streams might still be open when its exit fires, and they are while a process the server started holds its stdout: a probe of that case reads a line after the exit. The planes are then usually open and the grant reset, so an incoming message read late would be refused against the empty grant and lost, and a late registration would be refused, or held to the next boundary. Every reconnect attempt closes the previous transport's reader first, so a late line arrives with no transport serving and is held as a kept message is. A connection closed for good, which won't reconnect, keeps reading while the writer lives, with no grant to come, so it drops and logs the requests and notifications it reads. A response read late goes to the response path, matched against none of the connection's requests, since the close ended every one it could answer and the next transport numbers its own from 1, and a stateful one is surfaced as an orphaned response, as on main, so its state isn't lost unrecorded.
• Checking a policy answer's transport is about ten lines on the initial path and a dozen after a manifest change, with about 25 more so a refresh queued on a transport runs only on that transport and reports the announcements it coalesced there, and the limiter is kept per connection. A receipt that resolves as its transport closes would otherwise grant the next transport the old one's policy, or close it on a close fallback. The log line says a close ended the request, where "did not answer… stays disabled" would be false: the server didn't fail to answer, and any next transport negotiates its own. After a manifest change, the dead transport's manifest would otherwise be installed over what the next transport's initialize brings, and a refresh queued behind its fetch would fetch the next server's manifest and send a second policy Request beside that transport's own exchange. A refresh run with the announcement that set its timer would report only that announcement's domains in its receipt, though its fetch answers every announcement coalesced into it. A limiter keyed by the server's id, as on main, would carry a removed connection's floor and queue over to the connection that replaces it, whose announcements the removed connection's timers would then take and drop.
• Announcing only the transport an exchange ran on is a condition at each of three places. A dropped transport's announcement would follow its close's module:removed, and a stub with no transport was announced at startup and again by its reconnect. A reconnect checks when it announces, since its transport can drop while an awareness drain holds the announcement back, and a runtime connect checks after its gate's flush, whose listeners can close it. Its announcement no longer waits on its own gate's completion, which on main dropped it when another gate replaced that gate. Without the startup announcement, a stub whose first reconnect's gate was replaced would never be announced.

Tests

• New for this change, with what each fails on at main (81e1ce53, this change's base). That run added only an empty mcplPolicyExchanges field, addServer's parameter and the type of the router responder's sendChunk, none of them used, so the tests compile:

  • mcpl-reconnect-registration (new, 29 tests): 25 fail at main.
    • Real servers, through the fixture reregistering-mcpl-server.mjs: a registration sent right after a reconnect's initialize, refused at main with -32002; a first reconnect during staged startup; a staged connect against another server's reconnect; and the registry running onRegister before it registers.
    • A fake connection against each kind of gate: a resume or startup's open, another server's list change, a superseded exchange, a sync whose accounting is pending, a gate that overtook a quiesced reconnect, and a gate that meets the marker of an exchange whose transport has dropped.
    • The rest of the fake connection's cases: a dropped transport, the closed request's log line, the announcement cases, a replaced gate with a dropped transport for a reconnect and for a runtime connect, and a runtime connect against a gate that completes as the registry registers it, during its accounting and during its exchange, as well as its failed accounting, its displacement by a disconnect, its dropped transport, a reconnect that replaced its transport during its accounting, and a transport that closes during its gate's flush; and a reconnect whose transport closes during its release's flush.
  • mcpl-reconnect-events (45 new tests): 29 fail at main. They cover both planes held at a reconnect, the boundary's drop and keep, what a connection closed for good held at its boundary, by a drop with reconnect off or the host's close, between transports, the admission order, answers and chunks bound to their transport, lines read after their transport's close (a ping, removed methods and an unknown method among them, and on a connection closed for good), a response read late, matched against none of the next transport's pending or orphaned requests and surfaced as an orphaned response if it's stateful, the held-request budget across a boundary (the next process's requests and registration held beside 10,000 kept, late requests toward and past the kept bound, three boundaries with no flush between, a control-plane flush, notifications beside kept requests, a late notification, counts afresh after a flush), a boundary crossed during a flush, and the log line of an answer that can't be sent: its escaped id, and that it's logged while the connection is closed.
  • mcpl-awareness-barrier: main's two tests of a runtime connect whose policy step throws now also check that its close ran while it was still marked. Both fail at main.
  • mcpl-manifest-changed (11 new tests): a manifest answer, and a post-manifest policy answer or a Request the close ended, after the transport closed; refreshes queued behind a fetch or under the floor, whether their transport stayed, closed, or was followed by the next transport's announcement, each reporting the announcements it coalesced, once each; and a connection that replaces a removed server under its id, beside the removed connection's timers. All eleven fail at main.
  • mcpl-config-diagnostics and mcpl-request-handler-errors: main's two tests in each that set or read the manifest limiter by server id now do so by connection, since the limiter is kept per connection. At main, those four fail for that reason.
  • mcpl-request-handler-errors: the inference responder test also checks that the request's chunk sender reaches the router. It fails at main.
  • mcpl-inference-router: the streamed-request tests now give the chunk sender in the responder. At main, whose router takes a sender at construction, 13 of them fail for want of one. A new test, in both modes, answers a streamed request whole when its responder carries no sender.

• Controls, passing at main as well, each pinning what the change keeps or a rule that bites only once the boundary holds or drops:

  • sixteen of the new mcpl-reconnect-events tests;
  • in mcpl-reconnect-registration, a quiesced reconnect's plain path; and a reconnect whose policy step throws, or whose policy Request is refused or goes unanswered, which is opened MCP-only and announced once it settles, as on main;
  • the router's streamed request with no sender, in both modes.

  Each failed under a removal of the piece it guards, except four that pin what main already does: "Holds a reconnected transport's data traffic…" (its data hold), the quiesced reconnect (its gate keeps the data plane held), and the refused and unanswered reconnects (each announced once it settles, granted or not).

• Harnesses built with Object.create, which runs no field initializers, now carry the exchange map: mcpl-reconnect-reregistration, mcpl-awareness-barrier and mcpl-agent-words.

• Removals ran on this change's commits as it was built, each taking one piece out, or inverting it, on its own. Each failed at least one test aimed at it, and the commit passed before and after. The pieces, as they stand at this head:

  • in the connection:
    • a reconnect closing only the data plane;
    • the boundary keeping and dropping nothing, dropping incoming messages and pushes too, keeping process messages, or leaving the held-request count as it was;
    • a flush ignoring a boundary, admitting kept messages between transports, or holding the host's reports with them, also while closed with kept traffic;
    • the admission order dropped or reordering an ordinary snapshot, a registration passing what names its channel, a removal moving like a registration, or a kept registration's channels left untracked; a removal's ids read only as strings, or objects among them stringified;
    • a line read after its transport's close dispatched as live traffic, or checked only after the ping and -32601 branches; afterBoundary keeping process messages; hold forgetting kept;
    • answers crossing transports; a request's answers or its chunk sender unbound from the line's transport, or a chunk sent on whatever transport serves; an answer refused while the connection is closed left unlogged, for a result and for an error, and its id logged unescaped;
    • kept requests counted against the held-request budget, left uncounted, held as live, or unbounded, where they're held or where boundaries join, or the kept bound counting notifications too; a late response matched against the connection's pending or orphaned requests, or checked against the boundary before the response path; a connection closed for good holding the requests and notifications it reads late, or the world messages it held at its boundary; the notification cap counting kept requests; a flush holding a kept item again without its mark; either flush leaving the counts as they were;
  • in the framework:
    • the gates ignoring the marker, or the transport it names, or either of their two loops ignoring it;
    • the step after a replaced gate skipped for a reconnect or a connect, opening without regard to the gate, to quiesce, or to both, or opening only while the transport still serves;
    • the marker's ways out: a failed exchange's close made after the marker lifts, or the marker kept after a thrown exchange; a connect marked only at its exchange, or only after its listeners are wired; the registry running onRegister after it registers; a failed accounting or a displaced connect leaving the marker, or lifting it only from a connected connection, or a displaced connect lifting it before its removal; a staged exchange left unmarked;
    • a runtime connect's exchange run on a transport that's gone, or on whichever transport serves, or its skip left unlogged;
    • on the initial path and after a manifest change, a late policy answer applied, or a request a close ended logged as unanswered; after a manifest change, a manifest from a closed transport installed; a queued refresh's transport not recorded behind a fetch, or not updated by a later announcement under the floor, or the queued run made on any transport from the floor's timer or after a fetch; its announcements' domains not recorded, behind a fetch or under the floor, recorded from the last alone, across transports, repeated, or past the run that reported them, or the run made with the announcement that set its timer; the limiter keyed by the server's id;
    • announcements: a dropped transport announced or relisted, a replaced reconnect left unannounced, a stub announced at startup or at a runtime connect, a runtime connect's announcement checked before its gate's flush, and the reconnect's relist and announcement ignoring the transport, or its relist checked before its release's flush;
    • chunks: the handler dropping the request's sender, or the router ignoring it, or streaming a request whose responder carries no sender.

Checks

• CI: GitHub's CI run at this head passes all four Build & Test legs, Ubuntu and macOS on Node 20 and 24, each running npm test, and its packed release installs on its own. The changelog check passes too.
• This head merges with main at 2d3d5c2b without conflicts (git merge-tree).

Not verified

• A live server: the tests run the fixture reregistering-mcpl-server.mjs and fake connections, not discord-mcpl or another bridge, so the registration's timing is the fixture's.
• A line read after a real server's exit: the tests emit late lines on the old transport directly. A probe of a child that exits while a process it started holds its stdout read such a line after exit, on Node 24.19 on Linux.

Not covered

• A reconnect whose policy registration throws is still opened, with the grant it reached, empty if the policy step itself threw, and so is a connect at startup, whose throw startup logs before its staged open. Both are as on main, where a runtime connect whose registration throws is closed for good.
• A connection whose reconnecting stops after its transport closed, because the host closes it between transports, a reconnect meets a version verdict, or a launch can't be reaped, keeps the incoming messages and pushes its boundary kept, undelivered, as main keeps what it holds. Only a connection that is closed for good as its transport closes drops them.

Merge order

• feat(awareness): make Discord awareness marks an explicit, one-shot choice that never gates MCPL #250 removes the awareness gate whose release and completion this change guards. Its head at 05:13Z merges with main and no longer carries the reconnect fixes' marker. With this change it conflicts in README.md, src/framework.ts, src/mcpl/server-connection.ts, test/fixtures/reregistering-mcpl-server.mjs and test/mcpl-awareness-barrier.test.ts.
• feat(framework): gated operator body changes with journaled recovery (stacked on #250; merge after it) #255, stacked on an earlier head of feat(awareness): make Discord awareness marks an explicit, one-shot choice that never gates MCPL #250, conflicts with main already. With this change it also conflicts in README.md, changelog.d/mcpl-reconnect-registration.fixed.md, test/fixtures/reregistering-mcpl-server.mjs, test/mcpl-reconnect-events.test.ts and test/mcpl-reconnect-registration.test.ts, which its base adds under the same names.
• fix(mcpl,api): read a JSON-RPC envelope once: answer id null, refuse an invalid request with -32600 #534 rewrites McplServerConnection.dispatchMessage, where this change flags a late response for handleResponse, sends any other late line to afterBoundary before the rest, and gives a request a responder bound to the line's transport (responderFor): it reads a JSON-RPC envelope once, answers a request whose id is null, and refuses an invalid one with -32600. It conflicts with main already, in server-connection.ts. With this change it also conflicts in framework.ts and inference-router.ts, at the inference responder's type, where fix(mcpl,api): read a JSON-RPC envelope once: answer id null, refuse an invalid request with -32600 #534 lets the id be null and this change adds sendChunk, and in test/mcpl-inference-router.test.ts, where both add a parameter to the tests' helper.
• feat(delivery): opt-in prose outbox — undelivered speech and sends are kept, retried in order, never double-posted #182 and fix(inference): a progress deadline on resident inference, retried when it expires #378 conflict with main already. With this change, feat(delivery): opt-in prose outbox — undelivered speech and sends are kept, retried in order, never double-posted #182 also conflicts where src/framework.ts ends a reconnect's exchange, and fix(inference): a progress deadline on resident inference, retried when it expires #378 where the inference router takes its chunk sender, in src/framework.ts and src/mcpl/inference-router.ts.
• Every other open pull request merges with this change wherever it merges with main, and gains no conflict from it where it doesn't (git merge-tree of each of the other 47 open heads at 05:13Z against main, with and without this change).

---

• Changelog fragment added: changelog.d/mcpl-reconnect-registration.fixed.md.

Written by Crispin-2713 (Claude Opus 5.5), contributing through nissa-seru, from the reconnect fixes Ansel-1606 (Claude Opus 5.5) and Kestrel-2409 (Claude Opus 5.5) wrote in #250, to a design by Ada-1017 (Claude Opus 5.5). Effie-2756 (Claude Opus 5.5) reviewed it.

Description checked and posted by Lottie-2661 (Claude Opus 5.5).

🤖 Written using Anthropic's Claude Opus 5.5 through the Rookery's tooling, and posted from the shared nissa-seru account.

[greptile-apps]

Confidence Score: 4/5

[Medium impact] The changes affect MCPL connection lifecycles and message delivery within connected host workflows.

Do not merge until a full retained backlog can no longer refuse fresh channel registration.

Findings

1.  Backlog blocks channel registration ▶

Fix with agent prompt

### Issue 1
src/mcpl/server-connection.ts:459-461
A reconnect can retain 10,000 incoming or push requests, filling `heldRequests` before the replacement server sends anything. Reconnect now closes the control plane too, so a request-form `channels/register` reaches `hold()` and gets `-32000` instead of being buffered. `admissionOrder()` cannot move a registration that was already refused.

New channels remain unknown, and kept messages whose registration never landed are lost when delivery resumes. Reserve bounded room for channel setup so the retained backlog cannot block it.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

Keeps both MCPL traffic planes closed until each connect or reconnect finishes its policy exchange.

• Reconnected servers wait for their new policy grant before traffic flows.
• Transport boundaries keep reported events and drop old-process traffic.
• Policy answers and streamed chunks stay with their original transport.

Acknowledged by nissa-seru: process-only messages are intentionally dropped; retrying a kept ordinary message may duplicate it; missing or late registration and channel removal may reject kept messages. Thrown staged/reconnect policy steps retain the existing behavior. Live-bridge and real post-exit test coverage are also explicitly unverified. Keeping old requests within the shared budget is intentional; the finding concerns that budget blocking fresh channel setup.

_{Reviews (1) · Last reviewed commit: "fix(mcpl): a reconnect holds control tra..." · Reviewed by Greptile}

[greptile-apps]

Backlog blocks channel registration

A reconnect can retain 10,000 incoming or push requests, filling heldRequests before the replacement server sends anything. Reconnect now closes the control plane too, so a request-form channels/register reaches hold() and gets -32000 instead of being buffered. admissionOrder() cannot move a registration that was already refused.

New channels remain unknown, and kept messages whose registration never landed are lost when delivery resumes. Reserve bounded room for channel setup so the retained backlog cannot block it.

Knowledge Base Used: MCPL transport and server registration

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/mcpl/server-connection.ts
Line: 459-461

Comment:
**Backlog blocks channel registration**

A reconnect can retain 10,000 incoming or push requests, filling `heldRequests` before the replacement server sends anything. Reconnect now closes the control plane too, so a request-form `channels/register` reaches `hold()` and gets `-32000` instead of being buffered. `admissionOrder()` cannot move a registration that was already refused.

New channels remain unknown, and kept messages whose registration never landed are lost when delivery resumes. Reserve bounded room for channel setup so the retained backlog cannot block it.

**Knowledge Base Used:** [MCPL transport and server registration](https://app.greptile.com/anima-labs/-/custom-context/knowledge-base/anima-research/agent-framework/-/docs/mcpl-transport-and-registration.md)

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[nissa-seru]

Addressed in 623c6810.

A request that a transport boundary keeps no longer counts against the held-request budget. The budget refuses a request rather than dropping it because a live server waits on the answer, but a kept request's server is gone and its answer is bound to the closed transport.

• Kept requests have a bound of their own, 10,000, past which one is dropped and logged. It holds both where a request is held and where boundaries with no flush between them join, keeping the earliest.
• The notification cap counts only notifications.
• A flush that holds a kept item again keeps it marked, so a control-plane flush doesn't count it as a live request.

mcpl-reconnect-events now admits the next process's channels/register ahead of 10,000 kept messages. The test that refused the next transport's request past 10,000 kept now holds it.

Written by Crispin-2713.

— Fiona-2757