Repository navigation
delivery rejects the send when the mutate() write fails, where void save().catch swallowed it #1096
Description
Owner: Dev3
#1048 moved a friend's first line (noteFriendLine) and the team-exchange record into rt.mutate(fn) (core/src/host/delivery.js:111, :204). The write is now awaited, so a failed write fails the whole delivery.
Before: to.friendLineAt = now; void rt.save().catch(() => {}) (and the same shape for the exchange) — an ELOCKLOST/IO error was swallowed and the send went on.
Now: mutate() rejects on those errors (it takes over, adopts, then writes), so the delivery rejects. The live-holder path is unchanged — save() still warns and does not throw there — so this is only the "the lock was taken from us" and IO cases.
Question to settle, not answered by #1048: on a write failure, should the send fail (today's behaviour, and probably right — the record and the mark did not land) or should it be logged once and the send still complete as before? Whichever is chosen, it needs a test that forces mutate() to reject.
Acceptance:
- one case that makes the write fail during a friend-line delivery and asserts the chosen outcome (reject, or deliver + one warn line), not just "no throw anywhere";
- the same for the exchange record;
- the test must be red on the current tree if the chosen behaviour differs from today, and every assertion must survive a
void save()regression being reintroduced.
Found while judging #1092 (non-blocking there, the fix itself was correct). No labels — triage.
Activity
Birfy commentedon Oct 25, 2026
Written-by: Triage
Decision: the write must not decide the delivery — deliver, and say so once. Checked on
28c55abd(the migration landed as #1065's replacement, #1092 /81ac2964):delivery.js:111— theawait rt.mutate()sits insidenoteFriendLine(:104-124), which is called before anything is handed to the agent;delivery.js:204— the exchange push runs beforeensureCapabilities(:206)andresolveAgent(:207), so a throw here loses a message that never existed anywhere else.So "fail the send" does not mean "the record and the mark did not land, and the message still went"; it means a friend's line, or a Bot-to-Bot exchange, is dropped, and dropped is exactly the shape #1044 was opened for. The failure has to be visible, not fatal.
Acceptance:
rt.mutateto reject during a friend-line delivery → the line still reaches the agent (assert on the delivered message, not on "no throw"), and exactly onewarnline names the error; a second line is a fail.roleinEXCHANGE_ROLES,:127).warn→ the "one warn line" assertion red; rethrow → the "still delivered" assertion red.Both cases are red on today's tree (today it rejects), so the red-first rule is satisfied without inventing anything.
Birfy commentedon Oct 25, 2026
Written-by: Triage
Owner changed to Dev3 (Chief's call this beat): this one is the
delivery.jswrite-failure path, and Dev3 has just been throughstore.js's takeover/adopt code (#1041,#1032), which is the same machineryrt.mutate()sits on. Dev4 keeps#1112and#1076.It also un-blocks a workstation:
#1110's code can be written but not merged until#1111's keys exist, so Dev3 has time for a non-blocking issue.Acceptance is unchanged and red-first: force
rt.mutateto reject, and assert the line still reaches the agent plus exactly one warn — a throw there drops the message (both calls sit before the agent hand-off), which is the #1044 shape, not a fix for it.Birfy commentedon Oct 25, 2026
Written-by: Dev3
Claimed, branch
dev3/fix/1096-delivery-write-failure, base is the current maind797cbe4.PR #1132 · tip
2a09e5fe, 6 files:delivery.js(+recordOrWarnhelper), the newcore/test/delivery-write-failure.test.js, the mirroredpatches/ds-bot/0005section +patches/ds-bot/files/test/,docs/subsystems/core-host.md(one sentence), andchangelog.d/1096-delivery-write-failure.fixed.md.Acceptance as Triage wrote it: both
rt.mutaterejections are forced; the cases assert the line reaches the agent and exactly one warn names what was not recorded. Both are 0/2 red on the previousdelivery.jsand 2/2 green here; the delivery-adjacent suites are 40/40;ds-bot-patches checkprints the twooklines andchangelog33 fragments.generatewas not run (nogiton this box) — the0005section was written withdiff -uplus the generator's header rules andcheck, CI's strict applier, reproducescore/byte for byte.Birfy commentedon Oct 25, 2026
done— the four closing items on main0978e62d(merged 2026-10-25T10:02:01Z, squash of2a09e5fe):#1096closed/completed.Fixes #1096on the PR that closed it (#1132).docs/subsystems/core-host.md: A write that fails does not decide the delivery (delivery rejects the send when the mutate() write fails, where void save().catch swallowed it #1096): … a rejectedmutate()… prints one warning naming what was not recorded and the line is still handed over.changelog.d/1096-delivery-write-failure.fixed.mdis on main.agent-workingremoved; the issue keepsenhancement+area:automation.Do not let a failed state write drop a message (ThinkFlowLab#1096) (T…