Turbo Streams reconnection backoff lacks configuration surface

Goal

Allow applications to tune the exponential backoff schedule used when a Turbo Streams connection drops, so that reconnection aggressiveness can match infrastructure constraints such as load-balancer idle timeouts or upstream rate limits.

Constraints and uncertainty

Turbo 8.x implements a built-in reconnection loop with a starting delay near 500 ms and a ceiling around 30 s, but the algorithm is not documented and no public API exposes parameters for initial delay, maximum delay, jitter factor, or maximum attempt count. The client emits turbo:reconnect_attempt events, yet there is no event signaling that the backoff schedule has changed or that a configured retry ceiling has been reached. Applications using short-lived authentication tokens cannot inject fresh credentials during reconnect because the connection handshake is internal to the Turbo client. Background tabs also keep the socket open indefinitely, which may conflict with connection-count quotas on the server side.

Questions

1. Is there a supported mechanism to supply a custom backoff function or to read the current retry attempt number from the Turbo client?
2. Can the reconnection logic be paused or disconnected programmatically when the Page Visibility API reports a hidden tab, without triggering a full page unload?
3. What is the recommended pattern for re-authenticating a WebSocket connection that uses expiring tokens, given that Turbo does not expose a reconnect hook?