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
- Retry or stop
- Branch by code
- JavaScript
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
Show message, not content
Show message, not content
content on a failed turn still starts with Error:. Show outcome.error.message to end users — it is a fixed safe string.Honour retry_after_seconds
Honour retry_after_seconds
Wait the full
retry_after_seconds before resending. Fall back to exponential backoff only when it is null.Cap your retries
Cap your retries
Retry a few times at most, then surface the message.
retryable means a retry can succeed, not that it will.Don't confuse with connect errors
Don't confuse with connect errors
Turn errors leave the socket open and you decide whether to resend. Connect errors close the socket and drive the reconnect loop.
Related
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

