Errors & reconnection
Errors & reconnection
Errors & reconnection
Errors arrive as JSON events with type: "error". The connection stays usable unless a close frame follows immediately.
error.event_id (when present) is the event_id of the client frame that triggered the error — correlate it with what you sent.
error.type and error.codeAn error frame has both a type (broad category) and a code (specific reason). Match on error.code for actionable handling.
error.code referenceSee WebSocket connection for the full close-code reference.
Hydra sessions are stateful — when you reconnect, you get a new session_id and a fresh session.configure requirement. There’s no resume token.
A simple, correct strategy:
Two principles:
event_id correlation is the single most useful debugging tool. Always include a client-side event_id on outbound frames (UUIDs are fine):
When an error references your event_id, you know exactly which frame caused it.
error as fatal. Most aren’t. Only act on error if a close frame follows.1000. Idle close is normal. Reconnect only if the user is still engaged.server_full errors with no jitter is how you turn a transient outage into your own outage.tool_response_timeout deep dive