desktop: pending send retries forever, minting a new session ID per attempt ("Session not found") #60396

Summary

With the Desktop client connected to a remote server, a pending send retries forever. Each attempt mints a fresh session ID (and a fresh message ID), so the retry never converges: the server answers SessionNotFoundError and the app raises a new "Request failed — Session not found: ses_…" toast every few seconds. It began within seconds of the remote server restarting and ran at ~11 requests/minute for 3.5 hours.

Environment

• opencode version: 2.2.1 (server, opencode --version). The Desktop client reports 2.2.2; the server does not record the client version, so that number comes from the reporter.
• OS: Linux 4.19.0-gvisor aarch64 (server, EC2 + gVisor sandbox). Client OS: Unavailable — it connects from a separate machine.
• Terminal: n/a (Desktop client; no terminal environment on the server).
• Shell: n/a.
• Install/channel: server is latest from the npm platform tarball, pinned in the image, with OPENCODE_DISABLE_AUTOUPDATE=1; Desktop updates itself.
• Active plugins: none server-side.

Reproduction

Not reproduced from a clean state — observed on a live setup:

1. Desktop app connected to a remote OpenCode server over a tunnel.
2. The remote server process restarted (host reboot). Its session database was intact; nothing was deleted.
3. On reconnect, the app started retrying queued sends for sessions that do not exist on that server.
4. Each attempt issues GET /api/session/<new id> → 404, POST /api/session/<new id>/prompt → 409, GET /api/session/<sibling id>/message/<msg_st…> → 404, then repeats with new IDs.

Expected Behavior

A send for a session the server does not have should fail once with a terminal, actionable error, or be dropped/reconciled against the server. It should not mint a new session identity on every retry.

Actual Behavior

The loop never stops. The toast reappears with a different ID each time, including after dismissing it, and the server receives 11–12 requests per minute indefinitely.

Additional Context

Server-side log (role=server) over 3.5 hours:

• 2,385 responses with status 404 covering 2,376 distinct session IDs; the first was 9 seconds after the server booted. 425 prompt responses returned 409.
• Every failing ID is absent from session_v2, session_message, and the event sequences. The database is healthy: 698 sessions and 37,552 messages, nothing deleted or archived.
• Session IDs are time-sortable. Sorting the failing IDs against known session creation times places each one at the moment of its own request, i.e. they are minted per attempt rather than replayed.
• The message IDs in the retried prompts are msg_st<20 hex> (e.g. msg_stba57dd822d96fe95520a). The server's database contains zero rows in that format; it produces msg_<24 base62> (e.g. msg_189ef3fdc001NtyR0nMG9xWRbv). All 420 observed message IDs were distinct — no retry reuses one.
• This is not a client/server compatibility failure: a new session created from the same client against the same server worked end to end (7 messages, two prompts answered, tools ran).
• POST /api/session on 2.2.1 accepts a caller-supplied id (verified: create, get and delete with a chosen ID returned 200/200/204), so client-minted IDs are not the obstacle.
• Prompting an unknown session returns 404 SessionNotFoundError, and reusing a message ID on an existing session is idempotent (200). I could not reproduce the 409 path in isolation, so I am not claiming its cause.
• No POST /api/session appears in the log for the failing IDs. Caveat: successful creates are not logged (verified with a probe), so this is suggestive rather than conclusive.

Impact: continuous server load, unbounded log growth, a toast the user cannot clear, and repeated failures that point at a session the user cannot find. Nothing is lost on the server.

Screenshots of three toasts (distinct IDs) are available from the reporter on request.