[nissa-seru]

Problem

A deferred push's render describes "Everything that changed under this subject since the server's previous render of it" (RFC-006 §5.2). So a later render can't stand in for an earlier one the model hasn't read. §3.3 says so ("Subsequent rendered deltas cannot replace that prerequisite in an unread context"), and so does vector 49 ("R2 is rendered relative to R1 → B retains R1 before R2").

The coalescer keeps one occupant per subject and treats a render the way it treats a plain occurrence. That loses a render in two places:

• A render after a render (Coalescer: a retraction leaves an earlier render queued when two renders of one subject land in the same deferred queue #548). When a render settles while an earlier render of its subject is still unread in a deferred queue, it takes the subject's place. A retraction then withdraws only the later render and leaves the earlier one queued.
• A notice after a render. A notice that arrives after a render has landed unread displaces that render, as §5.1 has a notice displace "an unread plain occurrence". The next render covers only the new notice, so nobody reads what the removed one described.

Changes

• Renders form a run. The occupant marks a render and carries the earlier renders it builds on. A render that settles while a run is there joins it, after the renders already there.
• A run stays with one agent. A notice leaves an unread render in place, and its batch follows the run's agent. So does a batch opened while the render was under way, once the render lands unread, and its wakes go with it. The run's agent then renders the next batch, after the run.
• The receipt for that notice doesn't name the unread render as its prior, since it was neither displaced nor found consumed. It can still name an earlier version that was read.
• A retraction and a plain occurrence take the whole run, newest first. The walk stops at a render the host can't remove, which may be read. That render keeps the renders it builds on, and from then on what the walk left is history, with the subject's history unknown, as for any occupant whose removal fails. So a retraction's notice follows it.
• The coalescer checks each render of a run against the host. One a request has read, or that is gone, becomes history, and the run keeps the rest. So nothing the model has read is removed.
• The README's coalescing paragraph says that a render, or a notice, never replaces an earlier render the model hasn't read.

What each part is for

The code is all in src/mcpl/push-coalescer.ts: +50 −22 lines, without comments and blank lines.

• The rendered mark tells a render from a plain occupant. A notice displaces only the second (§5.1).
• The run (before) holds the renders a retraction or plain occurrence has to remove. Each is kept whole, so a render left alone after a later one is read is still marked a render. The other way is to fold an earlier unread render into the next. That would keep each render's content in the coalescer, and would move the earlier render's content to the later one's place, after anything that arrived between them.
• removeOccupant is the one walk that retraction and plain replacement share, newest first.
• refreshOccupant checking each render keeps the walk from removing a render the model has read, since the framework's removal doesn't itself refuse one. It also keeps a render still unread tracked when a later one was read first, or was removed by something else.
• Batches following the run's agent, wakes included, keep the next render in the context that holds the renders it builds on. A feature-set subject's renders land in the primary's window or queue, whoever renders them. When one lands in the primary's queue, the newer batch follows the primary, which renders it at its own turn's start, after the queue is written. One stored straight into the window leaves the batch's audience as it was.
• The receipt naming no unread render follows §3.3: a reported priorEventId "MUST identify an occurrence actually displaced or found consumed".
• snapshot() writing the occupant's eventId and placement keeps the stored shape as it is on main. restore() reads only those. After a restart nothing of the subject is tracked as unread, a run included, and its history counts as read, as for any stored occupant.

Tests

• New: mcpl-coalescer-render-run (12 tests), over a stub host whose every delivery waits unread in one agent's deferred queue, as Coalescer: a retraction leaves an earlier render queued when two renders of one subject land in the same deferred queue #548's test does. CoalescerHost leaves placement to the host, and the framework stores the assembling agent's own render directly, which mcpl-coalescing's tests below run. At main (76623a39, this change's base), ten fail and two are controls.
  • Coalescer: a retraction leaves an earlier render queued when two renders of one subject land in the same deferred queue #548's sequence: the earlier render stays, the later one lands after it, and a retraction removes both, newest first, auditing each.
  • A batch opened while a render was under way follows the render's agent, with its wakes, once the render lands unread.
  • A notice between two renders: the first render stays, its batch follows that render's agent, and the next render lands after it.
  • A notice over an unread run names, as its prior, an earlier render a request read.
  • A plain occurrence displaces both renders of a run, newest first, in the run's agent.
  • A plain occurrence over a run whose newest render can't be removed is appended as a fresh occurrence (a control).
  • A retraction whose removal fails at the newest render leaves the earlier one, and its notice follows (a control: main never reaches the earlier render).
  • A retraction whose removal fails at the earlier render appends its notice.
  • An earlier render a request has read stays, and a retraction removes only the unread one.
  • A run of three renders keeps placement order, a retraction removes it newest first, and a snapshot keeps the occupant's eventId and placement and nothing more.
  • A render gone from the middle of a run leaves the renders around it tracked and removable.
  • A render left unread after a later one was read stays a render: a notice leaves it in place, and a retraction then removes it.
• mcpl-coalescing, 86 tests as the runner counts them:
  • New: a notice arrives after a render has landed unread in a live turn's deferred queue, and one model call reads the first render, then the second. It fails at main, which drops the first.
  • Turned round: two tests in which a render waited in the primary's queue while a newer batch of its subject was open. The newer batch's wake is now the primary's, beside the primary's wake for the render. In one, another agent's assembly no longer renders that batch, and the primary renders it at its turn's start. The other still ends with one call reading both renders. Both fail at main.
  • The other 83 pass as on main, among them the second test whose turn reads both renders.
• Removals, each taking one piece out on its own. Each fails at least one test aimed at it, and the head passes before and after:
  • the settlement not joining the run, not narrowing a batch opened during the render, or narrowing it but leaving its wakes where they were;
  • the join keeping only each render's eventId and placement;
  • a notice displacing an unread render, or its batch not following the run's agent;
  • the receipt naming the run as the prior;
  • refreshOccupant checking only the newest render, or reading a render read or gone as everything ahead of it read;
  • the walk removing only the newest render, removing oldest first, going on past a render it can't remove, or leaving the history as it was after one;
  • a plain occurrence displacing only the newest render;
  • the snapshot writing the occupant whole.

Checks

• CI: all six checks pass at c7f5d457, the four Build & Test jobs (Ubuntu and macOS, Node 20 and 24) and the pack check in run 39220167084, and the changelog check in run 39220166982.
• This head merges with main at 6345d27d without conflicts (git merge-tree).

Not verified

• A channel subject whose binding moves between two renders. That the newer batch follows the run's agent, and so stays out of the newly bound agent's window, rests on reading framework.ts: coalescedAudience returns deliverTo alone when it's set. No test moves a binding.

Out of scope

• A write that bypasses deferral lands ahead of its agent's queued writes. By our reading of addMessage on main, if a render waits in an agent's deferred queue when that agent's own assembly stores the next render directly, the next render is read first, and the waiting one is read after it, untracked. Two things can leave a render waiting there: a turn-start flush that stops at a failed store write, or a render settling into the queue between the flush and the assembly. This is how addMessage orders writes on main, and it isn't changed here.

Merge notes

• fix: exempt chat:edited/deleted/reaction-remove markers from conversational treatment #168 (at a10eb51a) conflicts with this change in src/mcpl/push-coalescer.ts, in seven places: the occupant's type, retract, acceptPlain, acceptDeferred, two places in the render settlement, and snapshot(), where both write the occupant's eventId and placement alone. fix: exempt chat:edited/deleted/reaction-remove markers from conversational treatment #168 adds a firstView mark to the occupant and calls occupantLeaves() wherever an occupant leaves the subject. By our reading, this change keeps each render of a run whole, so a mark on one would go with it into the run.

---

• Changelog fragment added: changelog.d/548-render-runs.fixed.md.

Fixes #548.

Written by Crispin-2713 (Claude Opus 5.5), contributing through nissa-seru, to a design by Ada-1017 (Claude Opus 5.5). Meg-2646 (Claude Opus 5.5) wrote #548's reproduction, found that a render can't replace an earlier unread one and that a notice dropped one too, wrote the framework test of that notice, and read the change.

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: 5/5

[Medium impact] The PR appears safe to merge; no actionable issue was found in the changed code.

Summary

Keeps earlier unread renders in place when a later render or notice arrives.

• Unread renders stay in order, and later batches follow their agent.

Scope acknowledgments from nissa-seru: direct writes overtaking queued writes are pre-existing and out of scope; restart deliberately treats saved occupants as read, as before; moving a channel binding between renders is explicitly untested.

_{Reviews (1) · Last reviewed commit: "fix(coalescing): an unread render stays ..." · Reviewed by Greptile}