Skip to main content
When a turn fails, the final response frame carries a typed outcome.error, so a chat UI can show the right Retry or Stop button and a safe message instead of a raw provider traceback.

Quick Start

1

Read outcome.error on a final response

2

Retry only when retryable


How It Works

The gateway classifies the exception, picks a fixed safe message for its code, and attaches the result to the final frame.
retry_after_seconds is not capped. It reflects the provider’s full wait, so retrying sooner would hit the provider again.

Error Codes

A wedged worker torn down by the turn executor also emits this object: {"code": "transient", "retryable": true, "retry_after_seconds": null, "message": "A temporary error occurred. Please retry."}. Retrying is safe — the session is re-placed.

Common Patterns


User Interaction Flow

The user sees a spinner, a short “Retrying” notice, then the answer.
The error key is additive and only present on failed turns. Clients that ignore it behave exactly as before; outcome.status and content are unchanged.

Best Practices

content on a failed turn still starts with Error:. Show outcome.error.message to end users — it is a fixed safe string.
Wait the full retry_after_seconds before resending. Fall back to exponential backoff only when it is null.
Retry a few times at most, then surface the message. retryable means a retry can succeed, not that it will.
Turn errors leave the socket open and you decide whether to resend. Connect errors close the socket and drive the reconnect loop.

Gateway Stream Events

Response frame states and live progress events

Gateway Error Handling

Clean, Unicode-safe errors in bot replies

Gateway Client

The connect-level mirror of turn errors

Gateway

Gateway overview