fix(chat): stop stranding queued sends rejected before commit

[caregullin]

Why

Two latent bugs in the window where a chat session is still being created. Both are silent: the user sees a message accepted into the queue and then nothing, with no error and no visible failure state.

A pre-commit rejection stranded the message forever. A queued send rejected before commit was retried exactly once, and that retry bailed out if the session was not ready when the timer fired:

if (!isQueuedSessionReady(runtime, ...) || getQueuedMessageKey(retryHead) !== key || ...) {
  return;   // burns the single retry and gives up
}

During draft promotion the session is not ready yet, so the one retry is spent on the readiness check. Pre-commit rejection is silent and leaves no store transition behind, so nothing ever re-triggers the drain. LAWS/CHAT.md requires that "when a chat's session becomes ready, that chat's queue MUST resume dispatching its first message to that session" — this violated it.

Quitting mid-creation replayed into an unreachable id. Queues are keyed by session id, and a session that is still creating only has a client-local draft id. Persisting its queue means the next launch restores a record bound to an id no backend session will ever have, so it can never drain.

What

• useMessageQueue: replace the single-retry latch with exponential backoff capped at 30s. A retry that fires while the session is still not ready re-arms instead of abandoning the record, and backs off as it does so. Any later readiness transition resets the backoff to the initial 1s.
• useMessageQueue: bound rejections to 5 per payload while leaving the readiness wait unbounded. See the note below — this is the important half of the change.
• queuePersistence: skip queue writes for sessions with an unsettled creationState (pending or failed). The write becomes an explicit null, so quitting mid-creation drops the message rather than stranding an undrainable record.

Why retries are bounded but readiness waiting is not

Retrying until the session is ready is right for a readiness or ownership race. Applying it to every pre-commit rejection is not, because some rejections are permanent.

sendQueuedMessageWithAutoCompact returns false whenever compaction fails (useChatSessionController.ts:2062), and each failure appends an error notification and calls setChatState(sessionId, "idle") (useChat.ts:424-430). Since isQueuedSessionReady requires chatState === "idle", that failure reads as a readiness edge — which both reset the backoff and fell through to tryDrainQueuedMessage. So a persistently failing send did not retry every second; it looped as fast as compaction could fail, appending an error notification to the transcript every pass. A test driving twelve such cycles dispatched 73 times.

The ceiling is counted at the single drain choke point rather than in the retry timer, so every trigger is covered (timer, readiness edge, lease release, store subscription). The counter deliberately survives readiness edges — the transition a failed send causes must not hand it a fresh budget — while a user edit or a new head does reset it. The record stays queued with showInComposer forced true, so it remains visible and manually retryable.

Waiting for readiness stays unbounded, since giving up there is the original stranding bug. But it now backs off to the 30s cap instead of re-arming at a flat 1s: measured, an unready session woke 960 times in 16 minutes before this change.

Risk Assessment

Moderate — this is shared chat code on the send path, not behind any experiment flag, so it affects every user.

The behavior change is bounded to sessions that are not ready, not yet created, or persistently rejecting. A send into a ready session that succeeds is unaffected: the retry and rejection state both clear on success exactly as before.

The remaining judgement call is the ceiling of 5. Too low and a genuine multi-attempt ownership race gives up early; too high and a persistent failure appends more error notifications before stopping. Five spans ~31s of backoff, and the failure mode when it is wrong is a visible retryable record rather than a lost message. Reviewers should push back if a real race is known to need more.

Not addressed here: the rejection reason is not actually classified. finalize(false) is reached both from a thrown PreCommitSendRejectedError and from a plain false return, and the catch at the call site discards the error. Distinguishing ownership races from terminal transport/preparation failures by type would be a better fix than a count, and is a reasonable follow-up.

Validation: just check passes clean. src/features/chat passes 2505 tests across 169 files. Both new tests were confirmed to fail without the fix — 73 dispatches instead of 5, and [1000, 1000, 1000, 1000, 1000] instead of a growing backoff — so neither is vacuous.

References

• LAWS/CHAT.md — queue dispatch and readiness rules
• Split out of feat(home): pin a prompt to the homescreen #209, which surfaced the original bugs; that PR now stacks on this branch

Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 76151d4b50

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[morgmart]

🤖 Automated code review

APPROVE. Fresh static review completed against the exact three-dot comparison d67756c..57e06f6, with no publishable findings. The final self-check covered the queued-send retry and draft-session persistence flows; accessibility and localization impact; navigation and consent guards; async failure, never-ready, lifecycle, remount, timer, and race behavior; test honesty; architectural laws and project rules; duplicate overlap; and the evidence required for blocking severity. The supplied GitHub evidence was inspected: all eight reported checks for the exact head SHA completed successfully. Required checks still independently govern merge readiness.

Deterministic publication result: 0 blocking and 0 non-blocking finding(s) publishable; 1 duplicate(s) suppressed.

Pending checks: 1 check(s) are not complete.

This approval reflects the completed code review only; merge readiness remains governed by the repository's required checks.