Turbo Streams Connection Persistence After Authentication Failure

Answer

When the server detects that a user’s authentication has expired or been revoked, ActionCable (the WebSocket layer used by Turbo Streams) closes the connection immediately. No HTTP 401/403 is sent because the WebSocket handshake already succeeded; instead the socket is terminated with a close frame (typically code 1008 – policy violation). The Turbo Streams consumer treats this as a fatal error and does not keep the socket open or retry automatically; a new connection is only attempted after a page reload or when the developer reinstalls the stream consumer.

Confirmed facts

• ActionCable::Connection#reject_unauthorized_connection (or any call to reject) triggers an immediate WebSocket close.
• Server logs show a “Rejected connection” entry and the client receives a close event with code 1008/1000.
• Turbo’s Stream adapter does not implement reconnection logic for authentication failures; it only retries after a full page reload or manual reconnect.
• This behavior is consistent across Rails 6.0+ and Hotwire Turbo bundled with Rails 7.0+.

Likely explanation

Because the WebSocket connection is considered compromised once authentication fails, ActionCable does not leave it open for the client to keep sending updates. Turbo’s client‑side reconnection with exponential back‑off (introduced in Turbo 7.x) is reserved for transient network errors; an authentication rejection is classified as a permanent error, so the back‑off algorithm is not invoked.

Steps to handle this case

1. In ApplicationCable::Connection, ensure authentication checks call reject_unauthorized_connection when the token is invalid or expired.
2. On the client, listen for the WebSocket close event (or Turbo’s turbo:stream-connection-error if you have custom handlers) and show a message prompting the user to reload or re‑authenticate.
3. Avoid implementing automatic reconnection loops for auth failures; instead, rely on a full page reload after the user logs in again.
4. If you need to force a disconnect from elsewhere (e.g., after a token revocation), call ActionCable.server.disconnect(current_user) or invoke reject on the connection object from a background job.

Missing diagnostic detail

Can you confirm that the server log shows a “Rejected connection” message when the authentication token expires? If the log does not contain this entry, the connection may not being rejected at the WebSocket level, which would change the recommendation.