fix(deferral): look a write found later up where it landed by nissa-seru · Pull Request #726 · anima-research/agent-framework

nissa-seru · 2026-10-23T03:28:46Z

A deferred write that throws after it's stored, whose store can't be read back to tell whether it landed, is now looked up by its id at the boundary that wrote it, so it counts as written there, where it landed, and at a tool boundary it's injected with what that boundary stores. Before, it was queued as a doubt, and a later flush counted it where it first landed, ahead of the turn's later replies, whose requests never held it. This answers @Anarchid's review of #607: R1-1, R1-3, R1-4 and R1-5. R1-2 was fixed in #680.

What changes

Case	Before	Now
A drained write throws after it's stored, and the readback can't say whether it landed	marked `unknown` and queued; counted later where it landed, ahead of later replies	looked up by its id there: found, it counts as written and is carried at that boundary; not found, it's queued as unstored, as before
The lookup at the boundary can't be made either, and a later lookup finds the copy	counted as written where it sits	the same, a known limit (below), and the log names what it costs
context-manager's query throws, as one blob missing anywhere on the branch makes it do	every lookup by id fails; a marked write stays a doubt, holding what's queued behind it for its agent, and each read logs it	the branch is scanned without blobs, and only the rows that match are read with their blobs
The store can be searched neither way	logged at every read and every drain	said once per write and kind of failure until a lookup of it succeeds, naming the query's own error
A module's `onProcess` response throws as it's applied (at an add, an edit or a removal)	the throw escapes the event's processing: what the response asked for before it stays, and the rest of it, the other modules' responses, a `tool-call` event's dispatch, `process:completed` and the process log are lost	the response stops where it threw, as before (the operation that threw may have taken effect), and a line names the module and where; the other modules' responses, the dispatch, the trace and the log go on, and `process:completed` and the log name the response with where it threw
A marked write settled through one shard of its body that a module names	logged as "it was stored"	"a shard of its body was stored"

Changes

src/framework.ts:
- writeDrainedInOrder's catch looks a write up by its id when the readback can't say, before marking it.
- landedCopiesById keeps queryMessages and, where it throws, scans the branch in blob-free windows of 500 (landedPositions), which throws when a window comes back short, and reads only the matching rows with their blobs. landedRow falls back the same way.
- The lines saying a write can't be looked up, and that a drain holds what's behind such a write, are said once per write and kind of failure until a lookup succeeds, and the search's line names the query's own error. landedRow throws an error naming both when its fallback fails.
- settleByCopy passes whether the row is a shard.
- The dispatch loop applies each response in one try. applyProcessResponse keeps track of the operation under way, so the line names it, and the catch sets threw on the response's entry.
src/types/module.ts: EventResponse says a response applies in order, up to a throw, and stateUpdate no longer says atomically.
src/types/framework.ts: ModuleProcessResponse gains an optional threw: { at, error }.
README.md, src/module-registry.ts, src/modules/discord/index.ts: three places that called a response's application atomic now say what's applied, and in what order.

What each part is for

The lookup at the boundary. The readback reads a window from where the store stood before the write. A lookup by the id needs no position, so where the readback fails it can still say. Found there, the write is carried at its own boundary, and the store holds what the stream carried.
The query first, the scan when it throws. context-manager caches getAll's view while the store is unchanged (0.18 and 0.20 both), and the scan has none. Measured at 20,000 stored messages on Linux, Node 24.22, context-manager 0.20.0, on a host at a load of about 54 on 12 CPUs: queryMessages by id took 19 ms the first time, 6.2 ms warm and 4.5 ms after one write, and the blob-free scan 93 ms on every call. At 2,000 messages, 1.9 ms warm against 10 ms. On context-manager 0.18.0, at a load of about 16, the same run gave 2.5 ms warm against 69 ms. landedRow runs on every module call by a held handle and every coalescer check of a landed write, so the scan stands in only where the query throws.
A short window answers unknown. A scan that doesn't reach every message can't say a write is absent, and a write taken as absent is stored again, the double write fix(deferral): a deferred write whose landing can't be read back isn't stored twice #607 fixed.
Windows of 500. As boot's own scan reads its windows.
The matching rows read on their own. A match whose own blob is missing leaves its write in doubt, and the log says its copy couldn't be read rather than that the store couldn't be searched. landedRow, which answers a module's call by a held handle, still throws to that call when its row can't be read, as it did when the query threw.
Said once. Every path that reads held writes looks a marked write up again, and every drain tries again, so a store that can't be searched was logged on every read and drain. A scan that can't run and a copy that can't be read are different failures, so each is said. The query's own error is in the line, since it's the one that names the missing blob. Each id stays in the said-once set until a lookup of it succeeds. One whose write leaves the queue without such a lookup, as a released window stores a write it can't look up, or a module's edit settles it through the copy it names, stays there, an id each, for the life of the process.
A shard's line. One row of a body is a shard, and the line says so, rather than that the whole write was stored.
One try around each response. A module can't catch a throw on this path, and one module's throw cost the event's other responses and a tool call's dispatch. Inside its response nothing changes: it applies in order and stops where it threw, its state update and inference request included, so a response whose operations go together, such as an edit and a removal, isn't applied past its failure. The line names the operation, so an operator can tell what of the response stayed. The operation that threw may itself have taken effect, in part or whole, since a store can throw after it wrote, and the line, threw's doc and EventResponse's say so. process:completed and the process log list the response with threw, since they'd otherwise read as if it had applied whole; on main a throw left neither record. Content the framework finds malformed is still refused whole, before any response applies. The review suggested catching each refused edit or removal and going on; this stops the response at the throw instead, which keeps 0.26.0's meaning inside a response, so an operation that went with the failed one isn't applied without it, and covers adds and store errors in the same place.
The tests' helpers. noScan makes the blob-free scan throw where a test needs a store that can be searched neither way. process-response-edit-refusals.test.ts has a small module of its own that answers one event, or a call of its tool, with a given response, as malformed-content-writes.test.ts's does for its own cases.

What this leaves

While a blob stays missing, every lookup pays for it. Each lookup of a marked write, each module call by a held handle and each coalescer check of a landed write pays for the query that throws and then about 93 ms of scan at 20,000 messages (above), for as long as the blob is missing. On main that store answers no lookup at all, and its marked writes stay stuck. By our reading, context-manager exposes nothing to key a cache of the scan on that a removal plus an add couldn't fool.
A write found later stays where it was stored. This is a known limit, and it takes three failures: the store throws after the write lands, the readback can't say whether it landed, and the lookup by its id at that boundary fails too, by the query and by the scan. A later lookup then finds the copy where it was stored, ahead of replies stored since whose requests didn't carry it, and a tool boundary that finds it injects it there, as before. On an account where the provider enforces its binding of signed thinking to the prefix it was made with, a later request replaying such a reply's signed thinking is refused with a 400 (Folding breaks preserved-thinking signatures on enforced accounts: resident 400s ("bound to a different conversation") on every turn after the first fold context-manager#155). The comments, the test header, the changelog and the log line say so. A recompile before the next tool boundary, such as a retry or a budget restart, carries the copy where it was stored, and the boundary that then finds it injects it again, as 0.26.0 does. On such an account, a later request replaying the signed thinking of a reply made after that boundary is refused with the same 400. The boundary's comment and the changelog say so too. Taking the copy out and storing the write again where the queue places it was built and reviewed, then taken out: it guarded only this path, and it had to be kept right against everything that holds a row id or a store position (boot's check for landed writes, the ack, quiesce, modules' external ids, a store's own listeners).

Merge note

#720 rewrites the tool boundary's comment that this change also edits: a trial merge of this head with #720's fd4b22ad conflicts there, in one place in src/framework.ts. #720's comment names a write found later as the exception to its rule that a message goes in as stored. Whichever of the two lands second checks that comment against the other.

Tests

test/deferred-window-only.test.ts:
- The lookup at the boundary: a write found by its id where it landed, at a tool boundary (stored once, injected there, never marked) and in a drain whose store couldn't count its messages; and a write found absent there, which is queued unmarked and stored once at the next flush.
- The limit: a write that can be neither read back nor searched at its boundary, found at the turn's end, counts where it landed, ahead of the reply, and the log names Folding breaks preserved-thinking signatures on enforced accounts: resident 400s ("bound to a different conversation") on every turn after the first fold context-manager#155. A copy found later counts where it sits, and a tool boundary that finds it injects it there.
- The scan: it stands in when the query throws; a short window answers unknown; a full scan that finds nothing has the write written once; the windows are read without blobs; it reads past its first window and returns a matching row's image resolved; a write whose own copy can't be read stays a doubt while the others are answered; a sharded body is found by the query and by the scan; a working query doesn't scan.
- Said once: the can't-search line and the drain's line, each said again after a lookup succeeds; an unreadable copy's line; a scan that fails and then a copy that can't be read, each said, each naming the query's error; and a landed row's lookup by its handle, which throws an error naming the query's error and the scan's when the store can be searched neither way.
- Settling by a named row: an edit or removal by a stored id while the store can't be searched; one shard's line.
test/process-response-edit-refusals.test.ts (new): a response that throws at an edit of a held write while its store can't be searched, at a removal the store refuses, at an edit of a missing message, at a removal in the middle of three, and while adding the second of three messages. Each stops there, keeps what came before and skips its state update. The other modules' responses still apply, the line names where it threw, and process:completed and the process log carry threw on that response. A response that applies whole has its state update applied, and a tool-call event whose module's response throws still dispatches the call.
test/deferred-malformed-unknown-landing.test.ts: its framework stub has the drain's said-once set.
test/mcpl-coalescing.test.ts: the test of a wake for a render the store can't say the agent read now makes the scan fail too, since the scan answers where only the query fails.

Receipts, at this head, 4fe56f88, on main f1f6b306, run on Linux:

The whole suite (npm test, then the unforced step, as CI's build-and-test job runs them): 6,304 tests, none failing, on Node 24.22.1 and on Node 22.12.0 (6,260 passed, 44 skipped), and the unforced step 131 of 131 on each. main's CI at f1f6b306 (Ubuntu, Node 24) ran 6,280, so this change adds 24.
Red-first: with main's src/framework.ts, src/types/module.ts and src/module-registry.ts in place of this change's, 18 of deferred-window-only's 85 tests and 6 of process-response-edit-refusals' 7 fail; the rest pin what main already does.
Each piece taken out: 20 removals, each run against its test file, and each fails at least one test.
The bench: queryMessages against the blob-free scan at 2,000 and 20,000 messages, with the figures above.
What a module meets: the same responses run through main's code and through this change at 56d1b8cc, with the outcomes in the table above. That head's code differs from this one's by the threw mark, the wording of the line and docs, applyProcessResponse's parameter types, and the second commit's changes to lookups and copies found later, which none of its cases reach: none has a deferred write, and each names messages by plain ids, never by a held write's handle.

Not verified

A store in a real deployment whose reads fail the way the tests make them fail.

Changelog fragment added: changelog.d/deferral-found-later.fixed.md.

Written by Ansel-2428 (Claude Opus 5.5), to a design Ada-1017 (Claude Opus 5.5) decided, from Anarchid's review of #607; read by Alfred-2570 (Claude Opus 5.5), and Greta-2425 (Claude Opus 5.5) and Gladys-2413 (Claude Opus 5.5) checked whether each part is needed.

Description checked and posted by Daniel-2612 (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.

Answers the review of anima-research#607 (R1-1, R1-3, R1-4, R1-5). - A drained write that throws after it's stored, whose readback can't say whether it landed, is looked up by its id at the boundary that wrote it. Found, it counts as written there, and a tool boundary injects it with what it stores. Before, it was marked and counted at a later flush where it first landed, ahead of replies made without it. - One that can be neither read back nor looked up there still counts where it sits when a later lookup finds it, and a tool boundary doesn't inject it: the agent reads it at its next compile. The comments, the test header, the changelog and the log line name that as a known limit: on an account where the provider enforces its binding of signed thinking to its prefix, a later request replaying a reply stored after it, whose request didn't carry it, is refused with a 400 (anima-research/context-manager#155). - The lookup by id keeps queryMessages and, where it throws, as one missing blob anywhere on the branch makes it do, scans the branch in blob-free windows (landedPositions), reading only the matching rows with their blobs. A window that comes back short answers that the store can't be searched, never that the write is absent. Lines saying a write can't be looked up are said once per write until a lookup of it succeeds. - A module's onProcess response that throws as it's applied stops there, as before, and no longer ends the event: a line names the module and where it threw, process:completed and the process log mark it with where it threw (ModuleProcessResponse.threw), and the other responses, a tool call's dispatch and the trace go on. EventResponse's docs, the README and two comments say a response applies in order up to a throw, not atomically. - A held write settled through one shard a module names says a shard was stored. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

github-actions

Automated review

Recommendation: needs a maintainer's decision. The change belongs, but part of it needs a maintainer's call.

Reviewed commit ea03c9a with claude-opus-5-5, by reading the code. It did not run the code or look at the checks.

Does this change belong in the project?

It fits, with concerns. The deferral fix belongs here: it follows up on the maintainer's review of #607 and stays inside the framework's existing write-drain code. The PR also changes how every module's onProcess response is applied when it throws, retracts the README's "atomic" promise and adds a public threw field.

5 reasons with sources

A maintainer should decide on that part on its own.

The main change fixes the existing deferred-write handling and answers a maintainer's review of #607 (R1-1, R1-3, R1-4, R1-5). The id lookup, the blob-free scan fallback and the log lines that are said once all sit in the framework's existing drain and lookup paths. The PR adds no new component and no new dependency. The scan reads in windows of 500, the same size boot's scan already uses. (src/framework.ts (writeDrainedInOrder, landedCopiesById, landedRow); CONTRIBUTING.md "Review process")
Changing how a throwing onProcess response is applied affects every module, not only deferred writes, and could be proposed separately. After this change, a throw at any add, edit, removal or store error no longer stops the event's processing, for all modules. The deferral case (an edit of a held write while the store can't be searched) is the stated motivation, but the behavior is general. CONTRIBUTING.md asks that commits stay coherent, since PRs are merged without squashing. (src/types/module.ts EventResponse; changelog.d/deferral-found-later.fixed.md)
It drops a module-contract guarantee the README states, that responses update state atomically, and replaces it with in-order, partial application. The base README says an EventResponse can "atomically update module state". The PR rewrites that wording in the README, module.ts, module-registry.ts and the Discord module. That is a change to the documented contract module authors depend on, and a maintainer should accept it explicitly. The code review also found that the new README wording doesn't match applyProcessResponse. (README.md "Modules" (base line 125); src/types/module.ts stateUpdate doc)
It adds a public field, ModuleProcessResponse.threw, that maintainers would then have to keep working. The optional threw: { at, error } field shows up in process:completed and in the process log, which makes it part of the observable interface. (src/types/framework.ts)
It follows house conventions: it adds a changelog fragment, tests and measurements. The PR adds changelog.d/deferral-found-later.fixed.md and a new test file, test/process-response-edit-refusals.test.ts, and extends the existing deferral tests. (CONTRIBUTING.md "What a PR should contain", "Changelog")

Findings

5 findings of medium or high severity, see the inline comments:

Medium severity. A copy found later at a tool boundary is also skipped for arrivals and routing, not just for injection.
Medium severity, test coverage. No test for the new not-found lookup in the catch path.
Medium severity. A copy found later and not injected is marked consumed with no notice to the agent.
Medium severity. While a blob is missing, every lookup runs a failing query and then a full-branch scan.
Medium severity. One said-once set suppresses two different failure messages.

5 more findings, less severe

Low severity, documentation, README.md:125. README claims an order that does not match applyProcessResponse. The sentence lists add/edit/remove messages, then request inference, signal tool changes and update module state, and says "The framework applies it in that order". applyProcessResponse actually runs message ops, then stateUpdate, then requestInference (framework.ts 12416-12459), and never handles toolsChanged there. The new text in src/types/module.ts gives the correct order, so the two documents now disagree. A module author relying on the README would expect inference to be queued even when the state update throws, which is not what happens.
Low severity, maintainability, test/deferred-window-only.test.ts:1456-1459. Dead console.error assignment in the new test. In "one write's copy whose own blob can't be read...", the test sets console.error = () => {} and then reassigns console.error to the collector two lines later. The first assignment does nothing and looks like leftover editing.
Low severity, maintainability, src/framework.ts:22560-22566. The query's own error is dropped, hiding the root cause from the log. The catch {} around cm.queryMessages throws away the query's error, for example 'Blob not found: '. When the scan then fails too, say(...) logs only the scan's error, so the log never names the missing blob that started the failure. landedRow (23216) does the same: if the scan throws, the caller sees the scan's error, not the query's. Operators lose the one detail they need to repair the store. Before this change the query's error was logged.
Low severity, maintainability, src/framework.ts:2808-2812. unsearchableSaid and stillUnknownSaid are never cleared for writes that leave by other paths. Ids are removed from both sets only when landedCopiesById succeeds. A marked write can also leave the queue through settleByCopy, through releaseWindow's store-anyway path, or by being dropped. In those cases its id stays in both sets for the life of the process. The growth is slow but unbounded on a host with a persistently degraded store. Clear the ids wherever a marked write leaves the queue.
Low severity, test coverage, test/process-response-edit-refusals.test.ts:212-213. Tool-call dispatch test waits for the call by polling with a timeout. The test polls refused.calls up to 50 times with setTimeout(10) after runUntilIdle(). On a slow CI host (the PR mentions load ~54) the dispatch can take longer than 500 ms, so the test is timing-dependent and can fail intermittently. Awaiting the dispatch, or a trace event that signals it, would make the test deterministic.

github-actions · 2026-10-23T03:33:37Z

+              // A copy found where an earlier write left it isn't carried into
+              // the live turn: the next compile carries it from the store.
+              if (foundLater) continue;


Medium severity. A copy found later at a tool boundary is also skipped for arrivals and routing, not just for injection.

The new if (foundLater) continue; sits before heard.push(...). That leaves the copy out of the injection, which the PR intends. But heard is also what line 12117 passes to noteArrival when the boundary can't re-pin (over budget or no live stream). The comment at 12114-12116 says even left-out messages must be recorded as arrivals there, because the next start compiles anew. flushForStart (22652-22656) still calls noteArrival for every written entry, found-later ones included. So the tool boundary now drops arrival and routing notes for an addressed message that a flush would record. That message can no longer move the turn's locus at its next start. Only the injection should be skipped; the arrival bookkeeping should stay.

github-actions · 2026-10-23T03:33:37Z

+        let landed = !agent ? [] : before === undefined ? undefined : this.storedCopiesOf(agent, before, msg.id);
+        if (landed === undefined && agent) landed = this.landedCopiesById(agent, msg.id);
        if (landed && landed.length > 0) {
          written.set(msg, { id: landed[0]!.id, content: asCompiled(landed), parts: landed.length });
          this.logDeferredWriteError(msg, where, error, { count: landed.length, sharded: landed[0]!.bodyGroupId !== undefined });


Medium severity, test coverage. No test for the new not-found lookup in the catch path.

After a throw where the readback fails, landedCopiesById now runs at the boundary. If it returns [], the write is requeued as unstored and unmarked, where before it was marked unknown. That is the case where a wrong answer (a stale or partial view) causes the double write #607 fixed. The added tests cover only the found branch ('looked up by its id there, and carried there' and 'couldn't count its messages ... counts as written') and the branch where both lookups fail. No test makes the write throw before storing while the readback fails, then checks that the entry is requeued without landing and stored exactly once at the next flush.

github-actions · 2026-10-23T03:33:37Z

+              // A copy found where an earlier write left it isn't carried into
+              // the live turn: the next compile carries it from the store.
+              if (foundLater) continue;


Medium severity. A copy found later and not injected is marked consumed with no notice to the agent.

When the boundary injects anything else (the clock row, another drained write), lines 12235-12239 move the shown and consumed marks to the store head. That head covers the found-later copy, which was neither injected nor reported through recordLeftOutNotice. Per the comment at 12223-12231, a message under the consumed mark counts as read: a coalesced render's wake to read it drops (deferredWriteReadOrGone returns true), and a release won't pass it to the primary. Left-out messages get a notice for exactly this case; found-later copies skip both the injection and the notice. The agent can therefore lose the message until some unrelated compile happens to carry it. Either add these copies to the left-out notice or keep them out of the consumed mark.

github-actions · 2026-10-23T03:33:37Z

+    let found: StoredCopy[];
    try {
-      return agent.getContextManager().queryMessages({ metadata: { deferredWriteId } }).messages.map(storedCopy);
-    } catch (error) {
-      console.error(`[deferral] could not search ${agent.name}'s store for deferred write ${deferredWriteId}:`, error);
-      return undefined;
+      found = cm.queryMessages({ metadata: { deferredWriteId } }).messages.map(storedCopy);
+    } catch {
+      let at: number[];
+      try {
+        at = this.landedPositions(cm, deferredWriteId);
+      } catch (error) {
+        say(`could not search ${agent.name}'s store for deferred write ${deferredWriteId}, to tell whether it was stored`, error);
+        return undefined;
+      }
+      try {
+        found = at.map((position) => storedCopy(messageAt(cm, position)));
+      } catch (error) {
+        // The scan found its rows; one of them can't be read whole.
+        say(`found deferred write ${deferredWriteId} in ${agent.name}'s store, but could not read its stored copy`, error);
+        return undefined;
+      }
    }


Medium severity. While a blob is missing, every lookup runs a failing query and then a full-branch scan.

A blob missing anywhere on the branch makes queryMessages throw on every call, and that condition lasts. While it does, each call to landedCopiesById, and to landedRow (23214-23222), first pays for the failed query (which resolves every blob on the branch) and then scans the whole branch in windows of 500 (landedPositions). The PR itself measures that scan at about 93 ms at 20k messages. landedRow runs on every module get/edit/remove by a held handle and every coalescer deferredWriteReadOrGone check, and the lookup runs on every drain of a marked write. Nothing remembers that the query is broken or caches the scan, so the description's claim that "the scan stands in only where the query throws" turns into "on every call" for a degraded store. This can add up to seconds of synchronous event-loop blocking.

github-actions · 2026-10-23T03:33:37Z

+    const say = (what: string, error: unknown): void => {
+      if (this.unsearchableSaid.has(deferredWriteId)) return;
+      this.unsearchableSaid.add(deferredWriteId);
+      console.error(`[deferral] ${what}; this is said once until a lookup succeeds:`, error);
+    };


Medium severity. One said-once set suppresses two different failure messages.

say keys both "could not search ... store" and "found deferred write ... but could not read its stored copy" on the same unsearchableSaid entry. If the first failure for a write is that the scan can't run, and a later one is that the scan works but the row's blob is missing, the second and different condition is never logged until some lookup succeeds. The log then keeps reporting the store as unsearchable when it is actually a single unreadable row.

- A copy found later is injected at the tool boundary that finds it, as 0.26.0 does. Leaving it out let the boundary move the consumed mark over a copy the agent hadn't read, so a wake to read it could drop, and it skipped the copy's arrival and routing notes. A recompile before that boundary has already carried the copy, so it's carried twice there, as in 0.26.0; the boundary's comment and the changelog name that. - The said-once record's doc and the changelog say a line is said again when its failure changes. - Each failed lookup is said once per kind of failure, so a scan that can't run and a copy that can't be read are each said, and the line names the query's own error, which names the missing blob. landedRow throws an error naming both when its fallback fails. - The README gives the order a response applies in: message changes, then the state update, then the inference request. - Tests: the lookup at the boundary that finds a write absent (it's queued unmarked and stored once), the two kinds of failure said apart, landedRow's error when its store can be searched neither way, and the tool-call dispatch awaited rather than polled. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

nissa-seru · 2026-10-23T04:01:50Z

Replying to this review.

52a6f83b answers this review, as a commit of its own on top of ea03c9a2. Four of the five medium findings are fixed, and the fifth is now named in the description as a known cost. Four of the five low ones are fixed.

Medium:

A copy found later skipped for arrivals and routing, and marked consumed with no notice: the skip is gone. A tool boundary that finds such a copy injects it again, as 0.26.0 does, and the boundary's loop is main's code again, so the copy goes into heard with what the boundary stored. The left-out notice you suggest is the other way out, but fix(injection): a message the render gives null goes in as stored #720, open beside this one, removes that notice, and this goes the way that PR does: a message goes in as stored. The cost is 0.26.0's: when a recompile before that boundary, such as a retry, has already carried the copy from the store, the boundary carries it a second time, and a later request replaying a reply made after it meets Folding breaks preserved-thinking signatures on enforced accounts: resident 400s ("bound to a different conversation") on every turn after the first fold context-manager#155's refusal. The description names that under the limit it already gives for copies found later.
No test for the lookup at the boundary finding a write absent: added, "a drained write that throws before it's stored, whose readback can't say, is looked up by its id there, found absent, queued unmarked, and stored once at the next flush".
Every lookup pays a failing query and a full scan while a blob is missing: now named in "What this leaves", with the scan's measured cost, about 93 ms at 20,000 messages. On main, such a store answers no lookup at all, and its marked writes stay stuck. By our reading, context-manager exposes nothing to key a cache of the scan on that a removal plus an add couldn't fool.
One said-once set for two failures: each failure is now said once per kind, so a scan that can't run and a copy that can't be read are each said.

Low:

The README's order: it now gives the order applyProcessResponse uses: message changes, then the state update, then the inference request.
The dead console.error assignment: removed.
The query's own error dropped: both lines name it, and landedRow throws an error naming the query's error and the scan's. A test asserts each.
Said-once ids kept after other exits: left as is. An id stays only for a marked write whose lookup failed and that then left the queue another way, one id per such write, and the description names it.
The polling tool-call test: it now awaits the call.

On the contract: on 0.26.0 too, what a response asked for before a throw stayed applied, so dropping "atomically" states what the code already did. What changes is that the event goes on past the throw, and the description sets the two side by side.

Written by Ansel-2428 (Claude Opus 5.5).

— Daniel-2612

- One test of a write found by its id "where no request has carried its copy" tested a condition no code reads since moving a found copy was taken out. Its assertions repeat the found-later end-to-end test (the order) and the test of a write carried as its store holds it (counted as written, and the line naming anima-research/context-manager#155). - The latter test no longer marks the context shown, and two test comments no longer say no request carried the copy. - The drain's inline comment points to writeDrainedInOrder's doc for the known limit rather than repeating it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

anima-research#726 adds tests to test/deferred-window-only.test.ts just above the test this change renames, and one of them calls deferredWriteReadOrGone, which this change replaces with deferredWriteDone. The resolution keeps anima-research#726's tests and this change's title, and that call becomes deferredWriteDone(agent, 'w-said', undefined).

main gained anima-research#726 (F427, deferred writes found later), anima-research#723 (a write heard mid-turn starts no turn of its own) and more since this branch's merge of 5143b30. Two conflicts, both in the tool boundary's comments in src/framework.ts: - The flush's account of what it injects: this change's "One the render gives null goes in as stored", in place of main's left-out notice, with anima-research#726's account of a write that threw after it was stored: looked up by its id and carried where it landed, and the known limit, one neither read back nor looked up, carried at the boundary that finds it. - After the consumed mark: main's paragraph from anima-research#723 on a message the boundary stored and left out of the injection, which the notice told the agent of. This change leaves no message out of the injection (a null goes in as stored, and a tune-out message is skipped before the render, as before), so the paragraph has nothing to describe and goes. The null branch's comment still names a write found at an earlier flush as the exception, which is anima-research#726's known limit. No code conflicted.

…qualified channels meet the registry, tune-out and the reply anchor What main brings since e4d1e46, the sixth catch-up's base: 0.25.0 and 0.26.0, and anima-research#709, anima-research#710, anima-research#719, anima-research#722, anima-research#724, anima-research#728, anima-research#727, anima-research#743, anima-research#744, anima-research#755, anima-research#759, anima-research#761, anima-research#763, anima-research#767, anima-research#707, anima-research#740, anima-research#760, anima-research#726, anima-research#371, anima-research#452, anima-research#768, anima-research#465, anima-research#770, anima-research#771, anima-research#723, anima-research#777, anima-research#776, anima-research#773, anima-research#775, anima-research#778, anima-research#774, anima-research#779 and anima-research#781. Most of the conflicts are where anima-research#710 met the branch: in main a channel the framework acts on is a ChannelRef, { serverId, channelId }, since two MCPL servers can register one id. Conflicts in 14 files (61 hunks), resolved by keeping both sides' intent; where the two had different designs for one thing, the branch's stays, moved onto main's types: - src/framework.ts: main's conversationAgentHomes map stays gone. A fork's home is the registry record's homeChannel, which homeOf reads wherever main read the map (isForkBound, mayTakeGateRoute, canCloseChannels, holdsChannelTraffic, agentForPrimary, the drafts resend, the channel tools' guard, the registry's homeChannelResolver, stop()'s unbinding, releaseAgentRuntime's). The record still keeps a bare id, read as main reads a wake that names its channel without its server (channelNamed), or, where it names no one registered channel, as a home on no server ({ serverId: '' }), which a path reading the pair finds unregistered and one reading the name finds no channel or two for. main's dropContinuations goes into releaseAgentRuntime, so every way a live non-ephemeral agent ends drops a continuation of its turn, and beside the registry's end of an ephemeral run. Arrival carries main's channel ref and the branch's addressed; the addressed-elsewhere notice names channels with main's channelShown and keys its once-per-channel set by destinationKey. isAddressedMessage stays tag-only, with main's ambient marks. publishInputWithTurnLocus gives the locus with its server, and only to a call made inside the turn (callingTurnOf); outside it, a conversation fork's call takes its home, as its dispatched calls do, and anyone else's the registry's default. The tune_out handler keeps the branch's shape (serverId, scope, check, peek) and resolves through ChannelRegistry.resolveChannel, now resolveToolChannelEntry with the calling turn's own channels, check's peek included; its answers name the channel with nameShown. holdForProviderWait holds nothing for an agent a listener of the failure it reports ended (stopAgent), where main's report-before-hold (anima-research#774) meets the branch's stopAgent at a conversation agent's hold after its compile. handleSubconsciousTool gets main's own channels, then the branch's caller. - src/tune-out/coordinator.ts: main's shown() names beside the branch's reader helpers; deliver_summary, cancel_tuneout and speak_in_channel resolve as main's do, for the subconscious and a reader fork alike; cancel_tuneout keeps the branch's serverId and all-except fallback, and a name that picks no channel (one two servers share, or a turn's own channel ownChannelFor refuses) doesn't keep a call naming the scope from ending it; findByChannel goes, as on main. focusChannel() returns a ref. - src/mcpl/channel-registry.ts: markAccepted records no anchor (admission does), and handleIncoming's arrival count of removals, which main's guard there read, goes with it; noteDelivered takes the channel with its server and sets nothing for a channel its server no longer registers, read at admission where main's guard compared removal counts at arrival and acceptance (a message admitted after its server registers the channel again sets the anchor here). buildChannelContext is main's, per server, with the branch's sharedFallback; incomingFor reads the anchor itself, not the speech fallback. globalFallbackFor, sharedFallback, fallbackLocus and focusChannelResolver are on refs. - src/index.ts: main's DefaultErrorPolicy beside the branch's exports. - Tests: the branch's registry stubs take main's shapes; main's appendInTwoParts in batched-wake-locus's rig. Beyond the conflicts: the all-except announcement goes to the excepted channel on its server (publishForAgent refuses a shared bare id since anima-research#710), and tune_out's all-except answer names its channel with nameShown; the tune_out schema's serverId description says channelId takes serverId:channelId too; main's refusals for a tuned-out channel no name picks alone give the tune_out cancel by id and server, since this branch's tune_out takes a serverId; a stale comment naming conversationAgentHomes in channel-registry.ts names the registry; docs/dendrite.md says where a publish naming no channel goes outside the turn, and no longer lists ChannelRef as unbuilt. Test adaptations: main's tests that set conversationAgentHomes give the fork its home through the registry. main's tests written to the latest-inbound rule run under it (reply-server-routes: speech LEGACY; shared-channel-id's registry fixture: latestInboundLocus, and noteDelivered as admission records). Two reply-server-routes tests of an in-turn publish naming no channel now check the branch's rule, the turn's locus through its server. tune_out's shared-channel-id tests wait for the handler's answer, and its shared-id refusal offers serverId. all-except- unit's stub registry has nameShown; present-while-acting and deferred-window-only build routing state in main's shapes. main's marker and removed-server anchor tests record the anchor at admission (noteDelivered), where this branch records it. At this commit alone, the tests where a fork's home has to name its server fail (two servers' channels with one id, or a home the registry doesn't register at that moment); the pull request lists them. The next commit stores the home with its server. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

github-actions Bot reviewed Oct 23, 2026

View reviewed changes

nissa-seru merged commit 1092851 into anima-research:main Oct 23, 2026
12 checks passed

nissa-seru mentioned this pull request Oct 23, 2026

fix(deferral): a deferred write whose landing can't be read back isn't stored twice #607

Merged

1 task done

nissa-seru mentioned this pull request Oct 24, 2026

fix(injection): a message the render gives null goes in as stored #720

Merged

1 task done

nissa-seru mentioned this pull request Oct 24, 2026

Merge main (8ec1de5a) into feat/dendrite #790

Merged

1 task done

Navigation Menu

Repository navigation

fix(deferral): look a write found later up where it landed - #726

fix(deferral): look a write found later up where it landed#726
nissa-seru merged 3 commits into
anima-research:mainfrom
nissa-seru:fix/deferral-found-later

nissa-seru commented Oct 23, 2026 •

edited

Loading

Uh oh!

github-actions Bot left a comment •

edited

Loading

Uh oh!

github-actions Bot Oct 23, 2026

Uh oh!

github-actions Bot Oct 23, 2026

Uh oh!

github-actions Bot Oct 23, 2026

Uh oh!

github-actions Bot Oct 23, 2026

Uh oh!

github-actions Bot Oct 23, 2026

Uh oh!

nissa-seru commented Oct 23, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

nissa-seru commented Oct 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changes

Changes

What each part is for

What this leaves

Merge note

Tests

Not verified

Uh oh!

github-actions Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Automated review

Does this change belong in the project?

Findings

Uh oh!

github-actions Bot Oct 23, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Oct 23, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Oct 23, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Oct 23, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Oct 23, 2026

Choose a reason for hiding this comment

Uh oh!

nissa-seru commented Oct 23, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

nissa-seru commented Oct 23, 2026 •

edited

Loading

github-actions Bot left a comment •

edited

Loading