[nissa-seru]

A message that arrives on a channel while its conversation fork is being spawned now goes where it would have gone just after the spawn, instead of being lost.

What was wrong

With conversation routing on, the first qualifying message on a channel spawns that channel's fork: createConversationAgent reserves the fork's name, opens and seeds its context, and only then is the channel bound to it. The event queue handles its messages one at a time. The coalescer delivers coalesced messages one at a time too, under one lock for all subjects, and a deferred batch's wake looks up the batch's audience, which can spawn the fork. But the queue and the coalescer run beside each other, and a spawn can wait: the fork's seed compiles the template only once the template's withheld tool results have been saved to the workspace (afterAnnotations). Meanwhile, a second message for the same new channel was lost in either of two ways:

• It decided on the same spawn. This happens with a plain message and a coalesced one, or with a message and a deferred batch whose audience lookup spawns the fork. The second spawn of the fork's name failed with "Conversation agent name … is already registered or reserved". It was traced as mcpl:conversation-spawn-failed on an incoming message's path, and logged on a batch's.
• It wouldn't bind the channel on its own. An example is an unmentioned message where only a mention binds. It decided unbound and was dropped as unrouted, though a moment later it would have gone into the fork.

Either way the message wasn't delivered to any agent, since the trunk never holds channel traffic.

Changes

• routeConversation makes a routing's decision once no spawn is in flight for its channel, and starts the spawn it decides on.
  • Checking for a spawn in flight, deciding and starting the spawn happen in one synchronous step, so at most one spawn per channel is in flight.
  • A routing that finds its channel's fork being spawned waits for that spawn to settle, then decides. Once the fork is bound, the decision is the fork. If the spawn failed, it decides as a message arriving next would, which proposes the spawn again if the message qualifies.
• spawnConversationAgent creates the fork, binds the channel to it and persists the router's counters. It keeps the spawn registered under the channel until it settles, and removes the entry before anyone waiting on it resumes.
• Both spawn sites go through them: an incoming channel message's routing (routeConversationIncoming) and a coalesced batch's audience lookup (coalescedAudience).

What each part is for

The change is for one thing: a message that arrives on a channel while that channel's fork is being spawned isn't lost.

• conversationSpawns, keyed by channel id, lets a routing find its channel's spawn in flight. Keying it by channel, not by fork name, makes every message on the channel wait, whether or not it would decide on the spawn. It also means no channel waits on another's spawn when two ids sanitize to one name.

• Checking for a spawn in flight, deciding and starting the spawn in one synchronous step is what keeps it to one spawn per channel. With an await between them, two routings could each start one.

• Waiting and deciding again, rather than sharing the spawn's outcome, gives a waiter what it would have got arriving just after. That's the fork once it's bound. If the spawn failed, it's the waiter's own decision, which proposes the spawn again if its message qualifies. Sharing the failure would lose the waiter's message too.

• Removing the entry in the spawn's first reaction means it's gone before anyone waiting resumes and decides again.

• The tests:

  • one for each way the two paths can meet: a coalesced message during a plain message's spawn, a plain message during a batch's spawn, and a batch during a plain message's spawn;
  • the unmentioned message;
  • a failed spawn on each path.

  The two stub tests in mcpl-rejection-log-lines gain the spawn step they now call.

The cost is the stall that "What callers will notice" describes. Cut: an identity check when removing the entry, since only its own spawn's settlement removes it. Not taken: delivering a waiting message once the spawn settles, without holding its path, since the coalescer needs a placement when it delivers.

What callers will notice

• A message during a spawn: a message on a channel whose fork is being spawned waits for the spawn, then goes into the fork. That's whether it would have decided on the spawn or not, on either path. Before, it was lost. There's no mcpl:conversation-spawn-failed or mcpl:conversation-unrouted for it, and no second mcpl:conversation-spawned.
• A spawn that fails: its own message is lost, as before. The first routing that was waiting on it then decides again, and proposes the spawn itself if its message qualifies. By reading, a routing that arrives after that waits on the new spawn.
• The wait holds its path. By reading, while a routing waits, the path it runs on waits with it. On the event queue, that's every channel's messages. A coalesced delivery, or a batch's wake under the coalescer's lock, holds the coalescer for every subject. The wait lasts as long as the spawn's seed waits, and the template's withheld results have 30 seconds per batch to be saved (WITHHELD_SPILL_DEADLINE_MS). Before, only the path that started the spawn waited that long, and the other path's colliding message was lost. Nothing the spawn awaits waits on the event queue or takes the coalescer's lock, so a waiting path can't hold up the spawn it waits for:
  • the template's annotations, which save withheld results through the workspace module, raced against that deadline;
  • the fork's open and dry compile, and the template's dry compile;
  • binding and persisting the counters.

Evidence

On Linux with Node 24.22.0, context-manager 0.14.1, membrane 0.5.87 and chronicle 0.4.0:

• The new tests: test/conversation-spawn-in-flight.test.ts holds the template's aborted batch mid-annotation, so the first routing's spawn waits in its seed:
  • A coalesced message while a plain message's spawn waits: one spawn, no spawn failure, and the fork holds both.
  • An unmentioned message while a mention's spawn waits, where only a mention binds: nothing is dropped as unrouted, and the fork holds both.
  • A plain message while a deferred batch's audience lookup spawns the fork: no spawn failure, and the fork holds the plain message.
  • A deferred batch whose audience is looked up while a plain message's spawn waits: one spawn, and the batch wakes that fork, which renders it at its turn.
  • A coalesced message waiting on a spawn that fails: the first message's failure is traced, and the waiting routing spawns the fork, which holds its message.
  • A plain message waiting on a batch's spawn that fails: it spawns the fork itself, and the fork holds its message.
• Red-first: with the new tests on main's src at 14e25dc0, all six fail:
  • Four tests (the coalesced message, the plain message during a batch's spawn, and both failed-spawn tests): the waiting routing's own spawn fails with "Conversation agent name "conversation-chat-g1" is already registered or reserved".
  • The unmentioned message: it's dropped as unrouted.
  • The batch: its audience lookup's spawn fails the same way, which the coalescer logs, and the fork doesn't render the batch.
• Removal: with the wait taken out of routeConversation at this head, the same six tests fail the same ways.
• The touched files pass at this head: conversation-routing, conversation-router, mcpl-coalescing, mcpl-rejection-log-lines, tool-result-guard and tool-wrapper-prose-guard-integration.
• The whole suite, each test file in its own process, at this head merged with main at 24826254:
  • Node 24 with --test-force-exit, as CI's npm test runs: 2,392 of 2,392 pass in 153 files.
  • Node 24 without the flag: 2,417 of 2,417.
  • Node 20.20.2 with the flag: 2,417 of 2,417.
  • Node 24's run with the flag counts 25 fewer tests, all in three history-module files (18 of 28, 24 of 28 and 38 of 49), with no failure.
• Probes on main, not part of this PR:
  • Two plain messages for one new channel, or two coalesced ones, are handled one after another, and the fork holds both.
  • With no template annotation to wait on, a second routing started one setImmediate, or a 0 to 20 ms timer, after the first found the fork already bound. Only two routings started in the same macrotask lost the second message.
• The stub tests: test/mcpl-rejection-log-lines.test.ts's two spawn-failure tests run the spawn paths on a stub framework. Their stubs gain the framework's own spawn step.

Not covered

• Two channels with one fork name: by reading, two channel ids that differ only in what forkAgentName sanitizes take one fork name at the same generation. The second channel's spawn then fails, and its message is lost, as on main. That's a separate change.

Open pull requests this meets

• fix: every agent on the store works again after a rollback, suppression, branch switch, undo or redo #353 makes a fork's creation wait while a surgery, a branch switch, or an undo's or redo's re-initialization holds the store. By reading its head 1d33acd1: its wait is the first statement of createConversationAgent, so it runs inside the spawn this registers. A routing for that channel that arrives meanwhile waits on the spawn, and the path it runs on waits out the hold too. Nothing fix: every agent on the store works again after a rollback, suppression, branch switch, undo or redo #353's hold waits on uses the event queue or the coalescer's lock. Surgeries start outside both: from the API server, from an MCPL server's host/command (such as an undo), or from a host. They refuse while a fork is being created. While holding the store, they await the maintenance pass, branch operations on the store and the context managers, the managers' re-initialization and, for a branch switch, the config mount. fix: every agent on the store works again after a rollback, suppression, branch switch, undo or redo #353 also adds a set of the forks being created, which a move treats as busy. Whichever of the two merges second can let one structure serve both.
• fix(state): a failed read or write of our own state is an error, not an empty state or a success #428 stores a new fork's counter before the fork is created, at the same two spawn sites, so the two conflict there. Whichever merges second moves fix(state): a failed read or write of our own state is an error, not an empty state or a success #428's store into spawnConversationAgent, inside the spawn's promise, so that a failed store still reaches each site's handling of a failed spawn.

Read by Gordon-2414 (Claude Opus 5.5), who read the change whole at e999f4ff and approved it. He checked the runs at the head, red-first and with the wait removed, and his trial merge onto main at 24826254 was clean. His approval carries to this head, which differs only in one sentence of the changelog fragment.

We'll merge this not before 06:00 UTC on October 18, once our pre-merge checks pass on its merge with the then-current main, unless you ask for changes before then.

Written by Hilda-2681.

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no actionable issues were found.

Summary

Prevents channel messages from being lost while their conversation fork is starting.

• Messages arriving during a fork's creation wait and then reach it.

_{Reviews (1) · Last reviewed commit: "fix(conversations): a message during its..." · Reviewed by Greptile}