fix(web): stop a sent image message reporting "attachment not found"

[tusharbhardwaj-bk]

The problem

Sending a message with an image on bkt3 shows a red banner reading

Attachment 'image.png' cannot be sent: attachment not found (removed or expired).

on a turn that has in fact started and is already running. Reported on bkmain today; the claimed attachment file for that turn is on disk, so the message was delivered and the banner is describing a second, failed dispatch of the same turn.

The cause

Since upstream pingdotgg#8048 the web client uploads an image before sending and references it by a pending-… id, then releases that upload as soon as the server acknowledges the turn (releaseAttachmentUploads).

The fork's durable outbox can put the same queued turn on the wire twice:

• its replay loop is gated on isLocalSendBusy, which clears the moment the server's projection acknowledgement shows the new user message (hasServerAcknowledgedLocalDispatch) — that lands before the RPC reply removes the queue row;
• and dispatchPersistedOutboxItem deliberately tolerates a failed local removal, on the recorded assumption that "a failed local deletion leaves a harmless duplicate that the server will deduplicate by commandId".

That assumption held before uploads existed. It does not now: the duplicate is normalized in normalizeDispatchCommand before any commandId dedup, finds the pending upload already released, and fails — so a live turn is marked failed and gets a Retry/Edit banner.

The fix

The durable send path (startThreadTurnDurably) now records which turns it has on the wire and which it has delivered, and the replay loop consults that record:

• in flight → skip, the dispatch that owns the row will remove it;
• delivered → discard the row rather than skip it, because a row left in place latches the composer as permanently busy via deriveOutboxSendGate;
• rejected → forgotten, so retry and reconnect replay are unchanged.

The selection is a pure function in the fork-owned outbox module, so the call site inside ChatView.tsx shrinks rather than grows.

Surfaces

• Web/desktop — fixed here.
• Mobile — unaffected: it still queues images as inline data urls (toQueuedResendAttachments), so its replays carry their own bytes.
• Server — unchanged.

Verifying

• vp test run packages/client-runtime/src/outbox/ — 20 passed, 10 of them new in delivery.test.ts covering in-flight/delivered/rejected, identity and environment scoping, the bounded history, oldest-first ordering, and the legacy rows that omit an identity key.
• vp run --filter @t3tools/web --filter @t3tools/client-runtime typecheck — clean.
• apps/mobile/src/state/thread-outbox.test.ts and apps/web/src/components/ChatView.logic.test.ts — unchanged and passing.

No UI was added or restyled, so there are no before/after images: the visible change is that a banner stops appearing.

Written by Claude Opus 5 in T3 Code.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ No successful main baseline artifact is available yet. This run establishes the initial measurement.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	—	13.6 KiB	—	15.1 KiB	✅
Codex	Thread snapshot wire	—	7.2 KiB	—	7.3 KiB	✅
Codex	Live turn WebSocket wire	—	6.4 KiB	—	7.8 KiB	✅
Codex	Live turn WebSocket decoded	—	55.7 KiB	—	66.4 KiB	✅
Codex	Live turn messages	—	11	—	21	✅
Claude	Total thread wire	—	13.6 KiB	—	15.1 KiB	✅
Claude	Thread snapshot wire	—	7.2 KiB	—	7.3 KiB	✅
Claude	Live turn WebSocket wire	—	6.4 KiB	—	7.8 KiB	✅
Claude	Live turn WebSocket decoded	—	56.5 KiB	—	66.4 KiB	✅
Claude	Live turn messages	—	11	—	21	✅

Baseline: unavailable · PR result: 1a7136b · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 110.4 KiB
• Claude decoded thread snapshot: 111.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.