retry_after is not included in the JSON body. When retry timing is available
for an HTTP response, use the Retry-After response header.HTTP and WebSocket payloads
WebSocket close codes
WebSocket error frames use the same JSON payload shape as HTTP errors. If the server closes the socket after sending an error, the WebSocket close code is separate from the JSONcode.
Close codes
1012 and 1013 are not failures of your request. During a rolling
deploy each replica finishes the turn it is generating, then closes idle
sockets with 1012; a socket that was mid-turn receives its session_closed
event first. Audio you already received is complete up to the last chunk. A
handshake against a draining replica is accepted and immediately closed with
1013, so browser and server-side WebSocket clients receive the same portable
restart signal. The SDK retry delay defaults to one second.
The Python and JavaScript SDKs absorb this for you. If no audio for the current
turn has been delivered yet, they wait for the restart retry delay, reconnect to another
replica, resend the turn (session config and open contexts included) and keep
streaming, so a deploy is invisible to your users. Nothing is replayed once
audio has started, because that would repeat what the listener already heard,
and no turn is replayed twice. In those two cases the SDK raises the retryable
ServerRestartingError and you decide what to resend. The JavaScript SDK also
offers an onServerRestart callback for observing the silent replays; the
Python SDK logs them at INFO on the kugelaudio.streaming logger.
Handling errors
Useerror_code and code for application logic. Treat error as display
text only.