fix(desktop): recover first-submit draft when session.resume 404s (#67502)

[JonthanaHanh]

Summary

Submitting the first message of a new chat fails with "Prompt failed / session not found" when the gateway's in-memory session is cleared between session.create and the first prompt.submit (sleep/wake, network blip, gateway restart).

The sleep/wake recovery path calls session.resume without try/catch. For a never-persisted draft (no DB row because _ensure_session_db_row only runs on the first successful submit), the resume itself throws 4007 "session not found" — the error escapes to the outer catch and surfaces as the dead-end toast. Every retry hits the same loop.

Fix

Wrap the recovery session.resume in try/catch. When resume fails with session-not-found (the never-persisted-draft signature), mint a fresh backend session via createBackendSessionForSend so the message lands instead of being dropped.

Testing

• Existing chats still use resume+retry recovery (the try/catch only activates when resume itself 404s)
• New drafts that were never persisted now get a fresh session instead of the dead-end toast
• Non-session-not-found resume errors still surface normally

Fixes #67502

[alt-glitch]

This was generated by AI during triage.

Related to #67503, which covers the same first-submit double-404 recovery but also rehomes optimistic state and attachments and guards timeout/queued sends. This narrower patch needs a maintainer consolidation choice.

[teknium1]

Thanks for isolating the no-row first-submit recovery path. The premise is present on current main: session.resume is awaited without a catch after recovery begins at apps/desktop/src/app/session/hooks/use-prompt-actions/submit.ts:465-474, while tui_gateway/server.py:5617-5622 deliberately defers a new session's DB row until its first prompt.

Problems

• The proposed fresh-create fallback also runs after a timed-out initial submit, because the existing recovery condition accepts timeouts at submit.ts:465. A timeout may have reached the backend, so retrying in a new session can duplicate the message.
• It is not guarded to the foreground. Queue drains carry a stored target at submit.ts:147; createBackendSessionForSend changes selection and navigates at use-session-actions/index.ts:307-329.
• Attachment sync happens before prompt recovery at submit.ts:437; file.attach and image.attach_bytes require a live session (tui_gateway/server.py:10067, 10397), so attachment submits still fail before this fallback.

Suggested changes

• Restrict fresh creation to foreground double-404s only; retain error handling for timeout and queued sends.
• Handle initial attachment-sync failure and re-sync attachments after replacement creation.
• Add regressions for timeout, queue, and file/image paths.

Automated hermes-sweeper review.

[OutThisLife]

Superseded by #81261.

Thanks for this — the resume-itself-404s guard for never-persisted drafts is carried over there, with you credited via Co-authored-by.

Consolidating because this is one bug class across several PRs: main had three hand-rolled copies of the same stale-session recovery (prompt.submit, session.interrupt, session.redirect), and the RPCs that never got a copy — attach, /compress, checkpoint restore, tile actions — each failed the same way. #81261 makes it one resolver and routes every path through it, so the next session-scoped RPC we add inherits the fix instead of needing a fourth copy.