GeezerVison

Summary

Follow-up to #6525, which fixed a real bug — a send withdrawn by an unmount cleanup was silently lost — but paid for it with a client-side probe. This replaces that probe with the deduplication mechanism the codebase already owns, and deletes more than it adds.

The problem #6525 had to solve. A client cannot tell whether a request it aborted reached the server. lib/copilot/chat/post.ts never reads request.signal, so a request the server accepted still runs resolveOrCreateChat, persistUserMessage, and the billed turn to completion after the browser drops the socket (Next.js discussion). Retrying blind meant two chats and two billed runs; not retrying meant losing the message.

How #6525 answered it. It polled the orphaned stream for up to 2.5s before deciding. That number was a guess with no production timing behind it, the poll had to distinguish "the server has no such stream" from "we stopped looking" (conflating them re-sent after teardown, opening an uncancellable POST), and it still left a window open for a server slower than the ceiling.

How this answers it. IdempotencyService already backs webhook, polling, and billing deduplication here, and billingIdempotency exists for exactly this hazard — its own comment says a retry "would double-record usage — real money". Chat sends now claim through it, keyed on the client-generated userMessageId. Retrying is just reusing the id.

Server

• chatSendIdempotency claims each send. The key is scoped to the authenticated user — userMessageId is client-supplied, so an unscoped key would let one user probe another's sends and read back their chat id
• Storage is forced to Postgres for the same reason as billingIdempotency: a missed dedup is a second billed turn, so the key must survive Redis memory pressure. ~1-5ms is invisible next to the LLM call that follows
• The chat is recorded against the claim as soon as it resolves — the earliest a retry can be answered with somewhere to go. From there the claim is permanent; before there, it is released so a failed send stays retryable
• A repeat gets 409 naming the chat, deliberately the shape the pending-stream lock already returns, so the client's existing conflict handler reattaches rather than starting a turn

It fails open at every step. Deduplication saves a duplicate chat; the send is the user's message. An unreachable bookkeeping store must degrade chat, never take it down — an early draft failed closed and turned every send into a 409, which is exactly the outcome to avoid in production.

Client

Deleted with the probe: the poll and its two constants, the three-state result, the epoch plumbing that kept a superseded poll from re-sending, and the chat-adoption branch it required. The hook nets 67 lines smaller.

• Retry carries resumeUserMessageId through the same lanes fix(chat): stop losing sends aborted during mount-settling #6525 built (live event, stored handoff, queue entry) — same plumbing, a payload that is consumed synchronously instead of awaited
• Idle sends go back to calling startSendMessage directly. fix(chat): stop losing sends aborted during mount-settling #6525 routed them through the durable queue so recovery had a backing entry, which put every message in the product through the queue store, sessionStorage, and the dispatch loop for a rare path. Recovery never needed it — message, attachments, contexts, and id are all in scope at the abort. Both callers now share one handOffWithdrawnSend
• Removing the probe also removes a race it introduced: it awaited up to 2.5s between dispatchQueuedMessage's "re-read live" and the send, so an edit during that window sent pre-edit text
• startSendMessage takes its optional tail as an options object; it was at six positional parameters and the retry id would have been a seventh

Testing

Server: deduplicates a repeat without opening a second chat or stream, scopes the key per user, records the chat against the send, and still sends when the claim store is down. Client: reuses the original id on retry, and adopts the chat a deduplicated retry names. Plus the coverage #6525 earned — StrictMode double-mount, live-surface delivery, stored-handoff fallback, and the departing surface not claiming its own recovery event.

Each new test was confirmed red without its fix. 2058 tests, type-check, biome, and check:api-validation pass.

Known residuals

All three are deliberate, and each is better than what main or staging does in the same scenario.

Losing the claim store loses deduplication for that window — the fail-open trade above. The dedup window is 1 hour; userMessageId is never reused, so a longer one would be harmless.

A concurrent retry can be told to reattach to a turn that never starts. A retry arriving between storeResult and the turn starting gets 409 and reattaches; if the original then also fails, there is nothing to attach to. The client keeps the optimistic pair (the generic 409 branch does not roll back) and finalizes with an error, so the user sees their message with a failed response rather than losing it — and the original's finally releases the claim, so sending again starts a fresh turn. main loses the message with no error; staging re-sends and can duplicate the turn.

A failed storeResult degrades to no deduplication after 60s. The claim stays in-progress, which atomicallyClaimDb lets a retry reclaim once the lease expires, so a retry more than 60s later can start a second billed turn. Every alternative is worse: releasing on record failure duplicates immediately, and extending the lease to cover a turn (maxDuration is 3600s) lets a crashed pod poison the id for an hour. Leaving it in-progress still deduplicates for the first 60s, which is where recovery retries actually land — they fire from the unmount cleanup within milliseconds. Requires a Postgres write failure to reach, and logs Could not record the chat for this send when it happens.

Claim lifecycle

The load-bearing invariant, since it is easy to get wrong: the claim is permanent only once a turn is streaming. One line clears it, immediately before the stream response; finally releases it on every other exit.

Type of Change

• Bug fix
• Refactor

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)