send() waited forever when the server never answered. In apps that awaited
a read during page setup, a dropped response left the old layout on screen
with an empty body until a reload.
- sendTimeout (ms, default 0 = off): reject unanswered sends with
{ message, code: 'timeout' }. The clock starts at the call, so a send
stuck behind the connect or channel subscribe times out too.
- send(event, data, channel, { timeout, progress }): per-call override;
a bare function as 4th argument still means progress. timeout 0 opts out.
- A send that timed out before it was written is dropped from the queue
instead of going out late after a reconnect.
- Protocol events (websocket.*) never time out.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A page's send() queued behind a failing first connect hung forever — the
close handler dropped the ensureConnected() waiter without settling it, and
a throttled connect() was silently skipped, so nothing ever reconnected.
Symptom in apps: sidebar renders, page body stays blank until a reload.
- ensureConnected(): one waiter per outage, resolved by whichever attempt
succeeds next (no longer orphaned by a failed attempt)
- connect(): a call that lands on the reconnect throttle is retried when the
window opens instead of being dropped
- a replaced (connect(true)) or destroy()ed socket's late error/close no
longer wipes the live socket's state or schedules a reconnect
- destroy() cancels a pending auto-reconnect
- new opt-in `rejectOnDisconnect`: a send already written to a socket that
closes rejects with { message, code: 'connection_lost' } instead of
hanging (default off — unchanged behaviour for existing consumers)
- node:test suite (`npm test`) with a scripted fake socket covering each case
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Fabian @ Blax Software