fix(web): restore a submitted message to the composer when its turn fails

[sideeffffect]

Problem

When you submit a message in a conversation, the composer is cleared immediately. If the server accepts the turn and it then fails asynchronously — e.g. Claude runtime stream failed., Stale pending user-input request: … Provider callback state does not survive app restarts or recovered sessions., or a bare Runtime error — the failure surfaces only later via session.lastError, long after onSend has returned. The existing send-failure restore path only runs for a synchronous start-turn RPC rejection, so in the async case the typed text stays cleared and is lost for good, with no way to retrieve it.

Fix

Keep a snapshot of the just-submitted text (plus images and terminal/element/preview/review contexts) alive until the turn is confirmed accepted-and-clean, and restore it into an empty composer when the turn's session enters an error state.

• The restore decision is a pure, unit-tested helper deriveTurnFailureRecoveryAction in ChatView.logic.ts.
• It keys on session.status === "error" (a fresh, current-state signal), not on lastError — the server carries lastError forward across a new turn until the session next reaches ready, so keying on it would restore a stale prior-turn error. A session.updatedAt guard ensures a session that was already in error at send time can't trigger a spurious restore before the new turn begins.
• It never clobbers text the user typed after sending (the failed attempt also remains in the transcript), and it drops the snapshot once the turn completes cleanly.
• The synchronous and asynchronous failure paths now share one restore routine.

Scope: the primary onSend path in an existing/started conversation (the reported case). Plan-mode follow-up and "implement in new thread" are intentionally out of scope for this focused change.

Verification

apps/web typecheck, lint, and the touched unit tests pass, including six new cases for deriveTurnFailureRecoveryAction (async-failure restore, retyped-composer drop, stale-error no-op, clean-completion drop, still-running wait).

This is a state/logic fix rather than a visual one, so there is no meaningful before/after screenshot; the difference is whether the composer is repopulated after an induced runtime failure. Happy to attach a short screen recording of a forced runtime error if useful.

Claude Opus 4.8 via Claude Code.

---

Note

Medium Risk
Touches core send/composer state in ChatView with nuanced session/turn timing; logic is unit-tested but wrong edge cases could restore stale text or drop recovery incorrectly.

Overview
Fixes lost composer text when the server accepts a message but the turn fails later (runtime stream errors, stale callbacks, etc.)—cases the synchronous start-turn failure path never handled.

Adds deriveTurnFailureRecoveryAction in ChatView.logic.ts to decide restore, drop, or wait from pre-send session/turn markers and current thread state. Recovery keys on session.status === "error" with proof the session advanced (updated timestamp or new turn id), not on lastError, and skips restore if the user already retyped.

ChatView.tsx keeps a post-accept snapshot in pendingSendRecoveryRef, runs a recovery useEffect (with recoveryReevaluateTick for in-flight failures), and restoreComposerContentFromSnapshot shared with the existing synchronous send-failure path.

^{Reviewed by Cursor Bugbot for commit d9aa8ff. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Restore submitted message to composer when an accepted turn later fails

• When a turn is accepted by the server but the session later transitions to an error state, the composer is automatically restored with the original message content, attachments, and contexts.
• A new deriveTurnFailureRecoveryAction function in ChatView.logic.ts determines whether to restore, drop, or wait based on pre-send session/turn markers versus current state.
• On each send, ChatViewContent captures a recovery snapshot (prompt, attachments, contexts, annotations) and arms it after a successful turn start; a useEffect monitors thread state changes and triggers restoration when appropriate.
• If the user has already started typing a new message when the failure is detected, the snapshot is dropped to avoid overwriting their input.
• Sync rejection (turn never starts) now also uses the shared restoreComposerContentFromSnapshot callback instead of inline restoration logic.

^{Macroscope summarized d9aa8ff.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 430585d6-06e4-4fe1-a8d0-0ce284381e69

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR introduces new runtime behavior for automatic message recovery on async turn failures, with complex state machine logic handling multiple edge cases. The scope exceeds a simple bug fix and warrants human review given the behavioral implications.

^{You can add or adjust custom eligibility rules. Learn more.}

[sideeffffect]

bugbot run

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit d9aa8ff. Configure here.}