[Birfy]

Owner: Dev3
Reviewer: Reviewer
Written-by: Dev3
Fixes #1096
Tip SHA: 2a09e5f

Reproduce

deliver() writes twice before the agent has the message: noteFriendLine (the friend-line mark, core/src/host/delivery.js)
and the exchange record push. Both were made await rt.mutate(...) by #1048, and mutate() rejects when the lock was
taken over or the disk refuses — so today a failed write fails the delivery, and the line is dropped. It never existed
anywhere else: neither write is a copy of a message that is already stored.

New cases force it: rt.mutate = async () => { throw ELOCKLOST }, then deliver a friend's line and, separately, a
reply exchange; each case asserts the agent still received the message and that exactly one warning was printed.

What changed

• core/src/host/delivery.js: both writes go through one small helper, recordOrWarn(what, write) — try to write,
  on failure print one rt.warn line (ds-bot: delivery: <what> was not recorded: <error>) and continue. Nothing else
  about deliver() moved; the live-holder path (save() warns, never throws) is unchanged.
• core/test/delivery-write-failure.test.js (new): the two cases above, on a loaded runtime with the agent recording
  what it is handed.
• patches/ds-bot/0005-social-seams.patch + patches/ds-bot/files/test/delivery-write-failure.test.js: the mirror of
  the two files, made by hand because this box has no git (see "Not run").
• docs/subsystems/core-host.md: one sentence in the one-writer-per-home bullet — a failed write does not decide the
  delivery.
• changelog.d/1096-delivery-write-failure.fixed.md: a message no longer disappears when the write fails.

What I ran

• cd core && node --import ./test/harness-resolve.mjs --test test/delivery-write-failure.test.js → 2/2.
• The same test file against the previous tree's delivery.js (restored from the base tarball) → 0/2, both red
  ("the line is handed to the agent instead of being dropped"), then restored with cmp.
• test/delivery-write-failure.test.js test/mutate-writers.test.js test/bot-messages.test.js test/repeated-delivery.test.js
test/blocking-question.test.js → 40/40.
• node scripts/ds-bot-patches.mjs check → skipped pin (no git) / ok 10 patches apply cleanly in order /
  ok core/ equals ds-bot/ + patches/ds-bot/.
• node .github/scripts/changelog.mjs check → 33 fragments well formed.
• diff -rq against a pristine d797cbe4 unpack → exactly the six files above (plus the harness node_modules symlink).

Red without the source change

Yes — that is the point of this change and the reason it is not just a test PR: with today's delivery.js the two cases
are 0/2, because deliver() rejects instead of handing the line over. The knives from the acceptance hold too:
swallow the rejection with no warn and the "exactly one warning" assertion goes red; rethrow and the "still delivered"
assertion goes red.

Not run

• node scripts/ds-bot-patches.mjs generate — it needs git, which this box does not have. I wrote the 0005 section
  with diff -u plus the generator's own header rules (old-side start as the hint, no index line) and placed the new
  test file whole under patches/ds-bot/files/; check — the strict applier that CI also runs — applies all ten
  patches and reproduces core/ byte for byte.
• npm run verify, oxlint, npm run build — no oxlint binary or esbuild here; CI's tests-ok and Node 24 jobs
  cover lint, the client build check and the full suite.
• The smoke test — it needs a bench and a free port; the change is one helper in delivery.js, exercised by the new
  cases and bot-messages.

Risk

Low, and one-sided: the only behaviour that changes is that a write failure no longer loses the message. A failure is
still visible exactly once (no silent swallow), and the record genuinely stays unwritten — the next successful write
re-does it if it is a mark, and a lost exchange stays lost by design, since it is a note about the line, not the line.

[Birfy]

Verdict: PASS at 2a09e5f

Written-by: Reviewer

Judged on the merge tree: the six files onto main (9b00d6f6 when I built it; 267d3bcb after #1133 landed, and that one touches only .github/scripts, AGENTS.md and the Verifier skill, so nothing here overlaps). No conflict. All checks at this tip are completed; tests-ok success.

The change

recordOrWarn wraps exactly the two writes that sat between the caller and the agent — noteFriendLine and the exchange push — and nothing else moved in deliver(). That is the right pair: both land before the agent has the line, so a rejection there decided whether the message existed at all. The failure stays visible (one warning naming the record and the error) and the line is still handed over.

Ran: the new cases, the full core suite on the merged tree, a pristine 267d3bcb baseline for the same suite, the patch series check, and two knives.

$ cd core && TZ=UTC DSH_HARNESS=/opt/flybot node --import ./test/harness-resolve.mjs --test test/delivery-write-failure.test.js
# tests 2   # pass 2   # fail 0
$ TZ=UTC DSH_HARNESS=/opt/flybot node --import ./test/harness-resolve.mjs --test --test-concurrency=1 "test/*.test.js"
# tests 1297   (pristine main: 1295 — this PR adds the two)
# pass 1255
# fail 42      (pristine main: 42, the same 42 by name: no esbuild, no jsdom, no git, #896)
$ node scripts/ds-bot-patches.mjs check
skipped pin (no git): the tree hash cannot be computed here
ok   10 patches apply cleanly in order
ok   core/ equals ds-bot/ + patches/ds-bot/
$ node .github/scripts/changelog.mjs check
changelog: 38 fragment(s) in changelog.d/ are well formed

The 42 are byte-identical between the two runs (diff of the not ok lists is empty), so no failure is this PR's.

Knives, each on a copy of the merged tree:

$ # knife 1: delivery.js restored to main's version
not ok 1 - #1096: a friend line whose write fails still reaches the Bot, with one warning
not ok 2 - #1096: an exchange whose write fails still reaches the Bot, with one warning
# tests 2   # pass 0   # fail 2
$ # knife 2: keep the swallow, drop the warn line
not ok 1 - #1096: a friend line whose write fails still reaches the Bot, with one warning   (exactly one warning, not two and not none)
not ok 2 - #1096: an exchange whose write fails still reaches the Bot, with one warning     (exactly one warning for the failed record)

Both halves of the acceptance are load-bearing: reverting the source reddens "still delivered", removing the warning reddens "exactly one warning". The hand-written 0005 section is validated by check applying the series and reproducing core/ byte for byte, with CI's git applier agreeing.

Non-blocking

• recordOrWarn catches every rejection from rt.mutate(...), not only the lock/disk ones it was written for. A bug inside either callback (a TypeError on a field that moved) now prints one warning and continues instead of failing the delivery — visible, but no longer an exception anyone sees. For these two callbacks the in-memory state stays coherent and save() never runs after a throw, so I do not consider it a defect here; it is worth remembering the next time this helper is reused around a callback with more moving parts.
• The trade is at-least-once, not at-most-once: a lost friend-line mark means the same line can be marked again by a later delivery, and a lost exchange record is not rebuilt. The docs sentence says the write does not decide the delivery; it does not say the mark may be re-applied later. One clause would close that gap, not a blocker.