TEST_CHAT_RECOVERY

Test chat recovery

An accepted test turn continues when its browser connection closes. This applies to new messages and resumed interactions. For a new message, the server commits the session and queue item before it sends `message-queued`. This event contains `queueId` and `sessionId`. The composer clears the submitted draft on acceptance. When the consumer claims the item, it records the execution and registers its cancellation handle before it sends `execution-started`. The event contains `executionId` and `sessionId`.

The original connection receives live SSE events. After a reload or disconnect, the client reads the recorded transcript. It follows later `agentExecutionUpdated` notifications with fresh history reads. Each successful read replaces the recovered transcript. A failed read keeps the last known state. The client does not submit the message or resume request again.

`GET /projects/:projectId/agents/v2/:agentId/chat/:threadId/messages` returns `messages`, `openSuspensions`, and `activeExecutionId`. The active ID is present even before the first output. A `null` ID means that the recorded thread has no running execution.

All tabs of the owning user can follow the execution and request Stop. Other users cannot read or cancel a private test turn. Users can submit messages while a turn runs or waits for approval. Pending messages appear only in the queue panel. Each message enters the conversation when its execution starts. Typed answers to question cards still resume the suspended interaction. Waiting SSE requests do not block history recovery or approval actions.

Stop uses `DELETE /projects/:projectId/agents/v2/:agentId/chat/:threadId/executions/:executionId`. It requires `agent:execute` and the test owner. The server cancels the local execution or relays the request to the main that owns it. The response `{ cancelRequested }` reports the request. Recorded state determines completion. A late request cannot cancel a later execution. Suspended turns use the existing checkpoint cancellation path. Stop leaves pending messages in place. The next message starts after cancellation settles.

Execution admission and Stop use the same lock for the chat. Admission holds the lock until it creates the execution and registers its cancellation controller. Stop waits for this registration, including when another main receives the request. Admission releases the lock before model and tool calls start. This applies to queued messages, direct turns, and resumed turns. A startup that loses the lock must finalize its execution without starting the runtime.

Recovery guarantees the latest retained timeline, followed by newer snapshots. Updates can arrive in batches. Snapshots do not contain original text-stream IDs or every transient live event. Child text and reasoning share the existing 4,000-character limit for each delegation. Text beyond that limit is not part of recovery.

`GET /projects/:projectId/agents/v2/:agentId/chat/:threadId/queue` restores pending messages in their saved order. It requires `agent:read` and the Test session owner. `DELETE` on the same path with `/:queueId` requires `agent:execute`. Removal locks the session and rejects an item that has started. Successful removal discards its attachments. Queue changes use `agentMessageQueueUpdated` notifications across mains. Execution updates also refresh the queue. Neither notification replays stream events.

Accepted input survives backend process failure through the durable queue. Interrupted executions are not replayed. Valid approval checkpoints retain their place. The existing Agents enablement controls the feature. This contract does not include token replay or sender deduplication.

Users can drag future turns to reorder them. `POST /projects/:projectId/agents/v2/:agentId/chat/:threadId/queue/:queueId/reorder` takes `{ targetQueueId, expectedQueueIds }`. The expected IDs list pending messages in their current order. It excludes accepted steers. Under the session lock, the endpoint checks this order and moves the named message to the target message's position. It shifts the messages between them in the same transaction. It requires `agent:execute` and the Test session owner. Both messages must still be pending and unreserved for steering. A changed queue returns 409. The client refreshes the queue after success or failure. Reordering preserves message IDs, content, attachments, and the current execution. New messages join the end. Saved positions survive refresh and recovery.

Users can edit the text of a pending message. Edits retain its attachments and queue position. The update uses the session lock and fails if the consumer has claimed the item. Queue notifications refresh the edited text across mains. The execution-start event carries the accepted text so waiting streams do not show the original draft. If a message starts during editing, the editor keeps the unsaved text available to copy until the user dismisses it.

Users can send a queued Test message to the current execution. `POST /projects/:projectId/agents/v2/:agentId/chat/:threadId/queue/:queueId/steer` takes `{ executionId }`. It requires `agent:execute` and the Test session owner. The session lock protects reservation, claim, edit, removal, Stop, and completion. A request for an older execution cannot target a newer execution. The queue response includes `steerableExecutionId` and each item's `steeringExecutionId`.

A reserved message stays in the queue panel until the current model request and tool batch finish. The runtime then waits for the stream consumer to acknowledge an internal boundary. The consumer acknowledges it after preceding output reaches the recorder. This control event does not reach SSE. One transaction links the existing canonical messages to the execution, saves runtime context and message-ID timeline markers, and deletes the queue rows. Original content and attachment references stay unchanged. After the transaction commits, the runt