fix(desktop): recover a dead first-submit draft instead of "session not found"

[rapsealk]

Fixes #67502

Problem

The first message of a new chat can dead-end with a raw "Prompt failed / session not found" toast, losing the user's text with no way to retry.

A new chat's state.db row is only persisted by the gateway on its first successful prompt.submit (deliberately lazy, so abandoned drafts never leave "Untitled" rows). If the live session dies before that first submit lands — sleep/wake WS drop followed by the orphan reap, a backend restart, a stale cached runtime id — then:

1. prompt.submit fails with 4001 session not found, and
2. the sleep/wake recovery's session.resume fails with the same 4007 session not found, because there is no row to resume.

That second rejection was uncaught in useSubmitPrompt — it escaped to the outer catch and surfaced verbatim, and every subsequent submit into the draft repeated the loop.

Fix

• Wrap the recovery session.resume in try/catch instead of letting it reject the whole submit.
• When both the live id and the stored row report "session not found" (the never-persisted-draft signature), mint a fresh backend session via createBackendSessionForSend and land the message there — moving the optimistic message, the drift baseline, and the attachment sync over to the minted chat (attachments re-sync so @file: refs resolve in the new session's workspace).
• Introduce a mutable optimisticStoredSessionId for the optimistic/error-bubble state key so the re-homed send is never keyed under the dead stored id (which would cross-wire the session-state cache).

The fallback is scoped tightly; all of the following keep the existing surface-the-error behavior:

• timed-out submits — the prompt may have actually reached the backend, so re-sending into a new session risks a double-send;
• non-404 resume failures — a transport blip says nothing about whether the stored chat exists, and minting would split a real conversation in two (Desktop async delegation completions can revive an old session while follow-up prompts create a new session #55578 symptom b);
• background queue drains — targetIsCurrentView()-guarded, so a drain can never re-home the user's current view.

Tests

Four new tests in the "sleep/wake session recovery" block:

• double-404 → fresh create → submit lands in the minted session (and the optimistic message is re-seeded under it);
• non-404 resume failure → no session minted, original error surfaces;
• timed-out submit whose recovery resume 404s → no session minted (double-send guard);
• background queue drain hitting the double-404 shape → no session minted, view untouched.

apps/desktop: full vitest suite green (the one failure, toolset-config-panel.test.tsx, also fails on clean main in a full parallel run — pre-existing flake, passes in isolation); tsc --noEmit clean; eslint clean for the touched files.

🤖 Generated with Claude Code

[alt-glitch]

This was generated by AI during triage.

Related to #67502 and earlier merged recovery work #42688/#60874. This handles the distinct first-submit/no-row fallback and includes double-send and background-queue guards.

[teknium1]

Thanks for isolating the distinct no-row path after the earlier resume-success recovery work.

Problems

• The new recovery begins only after the initial syncAttachmentsForSubmit() call. On current main that call precedes prompt recovery (apps/desktop/src/app/session/hooks/use-prompt-actions/submit.ts:438) and invokes session-requiring image/file attach RPCs (tui_gateway/server.py:10067, tui_gateway/server.py:10397). Therefore a dead first-submit draft with a newly selected attachment still fails before the new double-404 branch can create a replacement session. The re-sync in the proposed branch helps already-staged attachments, but not this initial-sync failure.

Suggested changes

• Cover session not found from the initial attachment-sync phase, or establish the replacement runtime before staging attachments; add file and image regressions that verify attachment upload and prompt submission on the minted runtime.
• In the optimistic-state test, assert the stored-session argument passed to updateSessionState, not only the runtime id, because the cache maps runtime state through that stored id (apps/desktop/src/app/session/hooks/use-session-state-cache.ts:96-121).

Automated hermes-sweeper review.

[rapsealk]

Addressed both findings in d904d12:

Attachment staging before recovery — the recovery is no longer anchored to prompt.submit. The resume-or-mint logic is extracted into a shared recoverDeadRuntime helper invoked from both session-scoped failure points: the initial syncAttachmentsForSubmit (where file.attach / image.attach 404 on a dead runtime) and prompt.submit itself. A sync-time "session not found" now resumes the stored session — or mints a replacement on the double-404 never-persisted-draft signature — and then re-stages the attachments against the live runtime the recovery produced before continuing to submit. The prompt.submit failure point keeps its exact previous behavior (timeout double-send guard, non-404 resume failures, background drains all still surface the original error), just routed through the shared helper.

Regressions added per the review:

• recovers a dead draft whose FILE staging 404s before prompt.submit ever runs — file.attach (stale) → session.resume 404 → mint → file.attach (minted) → prompt.submit on the minted runtime with the re-staged @file: ref in the text.
• recovers a dead draft whose IMAGE staging 404s before prompt.submit ever runs — same shape through image.attach.
• rebinds attachment staging to the RESUMED runtime when the stored row still exists — pins that a real stored conversation rebinds via resume and never mints.

Stored-session keying — the optimistic-state test now asserts the stored-session argument passed to updateSessionState, not just the runtime id: the create stub re-homes selectedStoredSessionIdRef (mirroring the real createBackendSessionForSend), the test asserts the re-seed carries the minted stored id, and additionally that no post-recovery write still keys state under the dead draft's stored id (the cross-wiring hazard in use-session-state-cache). Backing this, the implementation's optimisticStoredSessionId re-pin now lives inside the shared helper so every recovery path gets it.

apps/desktop: target file 59 tests green, tsc --noEmit clean, full vitest suite green apart from the pre-existing toolset-config-panel.test.tsx parallel-run flake (also fails on clean main, passes in isolation).

[alt-glitch]

This was generated by AI during triage.

Re-triage confirms the reviewer-requested attachment-stage and stored-ID rehoming fixes are now present. Related to open #67539 (narrower) and #67575 (competing double-404 recovery); #67503 additionally covers initial file/image staging and stored-session optimistic-state keying, so this remains open for maintainer consolidation.

[GottZ]

This was generated by AI during triage.

Summary

Three open PRs address #67502's dead first-submit/double-404 path. #67539 adds a narrow resume-error fallback, #67575 adds guarded prompt-submit recovery and re-homing, and #67503 additionally handles pre-submit file/image staging, updates the stored-session state key, and adds regressions for the critical recovery boundaries.

Related pull requests

• fix(desktop): recover a dead first-submit draft instead of "session not found" #67503 best fix — (+569/-34) — n/a: The diff centralizes resume-or-mint recovery across both attachment staging and prompt submission, re-homes optimistic state under the fresh stored ID, and tests double-404, non-404, timeout, queue, file, and image paths. This supports the recorded best-fix assessment and the keep-open verdict; the earlier attachment-stage and stored-ID findings are addressed in the visible diff.
• fix(desktop): recover first-submit draft when session.resume 404s (#67502) #67539 duplicate — (+16/-6) — n/a: The diff catches a failed resume and mints a replacement, but it can do so from the timeout-enabled branch, lacks a foreground/queue guard, and does not recover attachment staging before prompt submission. Despite its keep-open verdict, the fuller visible diff in fix(desktop): recover a dead first-submit draft instead of "session not found" #67503 covers these same changes plus the identified guards and attachment paths.
• fix(desktop): handle double-404 when session.resume fails during submit recovery (#67502) #67575 duplicate — (+122/-16) — n/a: The diff adds double-404, timeout, and queue distinctions plus attachment re-sync after replacement, but post-recovery state updates remain keyed through the pre-recovery stored ID and no regression tests are added. Despite the COMMENTED keep-open review, that review documents the stale-ID association and insufficient first-draft gating, while fix(desktop): recover a dead first-submit draft instead of "session not found" #67503 visibly carries the fresh stored ID and corresponding tests.

Duplicates

#67503, #67539, and #67575 are competing implementations of the same #67502 recovery; #67539 and #67575 can be treated as superseded duplicates of the broader #67503 implementation.

Suggested consolidation

Keep #67503 open with a salvage path: retain its shared attachment/prompt recovery, fresh stored-ID re-homing, timeout/queue safeguards, and regression coverage for maintainer consolidation. Close #67539 and #67575 as duplicates of #67503 because their visible diffs leave respectively the attachment/timeout/queue gaps and the stale stored-ID/test gaps documented above.

Complex graph

flowchart LR
    classDef open fill:#dbeafe,stroke:#1d4ed8,color:#1e3a8a
    classDef merged fill:#dcfce7,stroke:#15803d,color:#14532d
    classDef closed fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    classDef unverified fill:#f3f4f6,stroke:#9ca3af,color:#374151
    classDef best stroke-width:3px,stroke:#b45309
    classDef target stroke-width:3px,stroke:#4338ca
    I67502(["issue #67502 (open)"])
    subgraph Dup67503 ["PRs duplicating each other"]
        P67503["PR #67503 (open)"]
        P67539["PR #67539 (open)"]
        P67575["PR #67575 (open)"]
    end
    P67503 -->|best fix| I67502
    class I67502 open
    class P67503 open
    class P67539 open
    class P67575 open
    class P67503 best
    class P67503 target
    click I67502 "https://github.com/NousResearch/hermes-agent/issues/67502"
    click P67503 "https://github.com/NousResearch/hermes-agent/pull/67503"
    click P67539 "https://github.com/NousResearch/hermes-agent/pull/67539"
    click P67575 "https://github.com/NousResearch/hermes-agent/pull/67575"

Loading

Graph: solid arrow = fixes / best fix, dashed arrow = partial or unverified (see edge label); boxed group = PRs duplicating each other; amber border = best fix; indigo border = target; gray node = closed (state tag in the node label).

Cross-PR triage: Reviewed 3 pull requests and 1 issue in this complex. Each diff was read against this issue; Assessment working set: 37 kB of PR diffs, 9 kB of issue/PR text, 5 kB of discussion (7 comments), 4 verify verdicts. verdicts reflect diff content, not PR titles. Part of an automated triage batch.

[OutThisLife]

Superseded by #81261.

Thanks for this — the first-submit draft recovery 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.