Web: first send on inactive never-started session fails with resume_unavailable (409)

[heavygee]

Summary

When a session was created (e.g. from the web or runner) but the agent never started—no user messages and no agent thread id (cursorSessionId, claudeSessionId, etc.)—the session can be archived/inactive. The web UI shows "Session is inactive. Sending will resume it automatically." but the send path calls POST /api/sessions/:id/resume, which returns 409 resume_unavailable because there is no agent session id to resume.

The user's draft is never sent (POST /messages is never reached).

Repro

1. Create a session in a directory (cursor flavor) where the runner never spawns the agent (or archive before first turn).
2. Open the inactive session in the web app (0 messages).
3. Type a message and send.

Expected: First message starts the runner in that directory (fresh spawn) or the UI shows a clear, actionable error.

Actual: POST /resume → 409 resume_unavailable; no message POST; misleading auto-resume banner.

Environment

• HAPI web + hub
• Observed on operator session 29f35bbf-2b1e-4eee-918e-52419aea71c2 (archived, 0 messages, cursor flavor, no cursorSessionId)

Related

• bug(web): queued message bar stale after CLI consumes (global SSE skips messages-consumed) #758 (queued bar / global SSE messages-consumed) — separate UX bug
• cursor: resume_unavailable when cursorSessionId never persisted (early exit before init) #744 / fix(cursor): persist resume id early and return 409 for resume_unavailable #745 — resume id before init when CLI used --resume (different path)

Suggested fix

• Hub: allow resumeSession to fresh-spawn when path exists, no agent resume id, and no prior user messages.
• Web: do not promise auto-resume when resume is impossible; guard resolveSessionId before calling resume.

[github-actions]

This matches the current code path.

For inactive sessions, the web send path calls resumeSession() before starting the message mutation. If hub resume fails, useSendMessage returns before api.sendMessage(), so POST /api/sessions/:id/messages is not reached. On the hub side, resumeSession() first calls resolveLocalResumeTarget(), and that currently requires a flavor-specific agent resume id. For a cursor session with no cursorSessionId, it returns resume_unavailable, which the HTTP route maps to 409.

The suggested hub fix direction is consistent with the existing lower-level spawn API: spawnSession() accepts an optional resumeSessionId, but the current resumeSession() path never gets there when resolveLocalResumeTarget() cannot produce an agent id. The web banner is also too broad because it promises auto-resume for any inactive session, while the current resume path can reject before sending.

Relevant code:

• web/src/router.tsx:295 - inactive session send resolves through api.resumeSession() before message send.
• web/src/hooks/mutations/useSendMessage.ts:138 - resolveSessionId runs before mutation.mutate().
• web/src/hooks/mutations/useSendMessage.ts:147 - failed resolve returns false, so the message mutation does not start.
• web/src/api/client.ts:312 - resumeSession() posts to /api/sessions/:id/resume.
• web/src/api/client.ts:325 - actual message send posts to /api/sessions/:id/messages only after the resolve step.
• hub/src/web/routes/sessions.ts:134 - resume route delegates to engine.resumeSession().
• hub/src/web/routes/sessions.ts:143 - resume_unavailable maps to HTTP 409.
• hub/src/sync/syncEngine.ts:545 - local resume target requires an agent resume id.
• hub/src/sync/syncEngine.ts:546 - missing agent resume id returns resume_unavailable.
• hub/src/sync/syncEngine.ts:635 - resumeSession() exits on that target error before spawning.
• hub/src/sync/rpcGateway.ts:107 - lower-level spawn supports optional resumeSessionId.
• web/src/components/SessionChat.tsx:560 - inactive-session banner always says sending will resume automatically.

---

HAPI Bot