WebSocketManager reconnect bugs: subscriptions created after the first connect are not re-sent after a reconnect, while subscriptions created before the first connect are re-sent again on every reconnect. The suggested fix is to replay active_subscriptions on reconnect and clear queued_subscriptions after the first connect.
This article summarizes the reported failure mode, affected code locations, and the proposed correction from Hyperliquid Python SDK issue #338, reported on Nov 12, 2026. It is a reference summary of a public issue report, not a verified platform-confirmed patch.
Reported symptoms
According to the issue, after a WebSocket reconnect:
- Subscriptions created after the first connect, such as
userEvents,orderUpdates, anduserFills, are silently never re-sent. - Subscriptions created before the first connect are duplicated on every reconnect.
- Bots can lose fill or order-update streams after a single disconnect.
- Non-idempotent handlers can double-count pre-connect subscription data, with duplication growing on repeated reconnects.
Affected code locations
The issue points to hyperliquid/websocket_manager.py in the Python SDK:
on_open, approximately lines 127–131subscribe, approximately lines 133–152queued_subscriptions, approximately line 82
on_open()only replaysqueued_subscriptions.queued_subscriptionsis only populated before the first connect.- Subscriptions made after connecting live in
active_subscriptionsand are never re-sent after a reconnect. queued_subscriptionsis never cleared, so pre-connect subscriptions are re-sent again on each reconnect.
Failure sequence
The issue includes an offline reproduction using a stubbed WebSocket module, with no network or wallet required. The reported sequence is:
- Subscribe to
allMidsbefore connecting. - Connect, then subscribe to
userEvents. - Simulate a reconnect by calling the
on_openpath again.
- Only
allMidsis re-sent. userEventsis not re-sent.active_subscriptions["allMids"]grows to 2 entries.- A single message triggers the callback twice, or N times after N reconnects.
Suggested fix
The issue suggests two changes:
- On reconnect, replay
active_subscriptions, not onlyqueued_subscriptions. - Clear
queued_subscriptionsafter the first connect.
## Pseudocode based on the reported fix; not a verified SDK patch.
def on_open(self, ws):
if self._first_connect_done:
for subscription in self.active_subscriptions:
self._send_subscription(subscription)
else:
for subscription in self.queued_subscriptions:
self._send_subscription(subscription)
self.queued_subscriptions.clear()
self._first_connect_done = True
The exact implementation should follow the SDK’s actual data structures and subscription-sending method. The key idea is that every active subscription should be resubscribed after a reconnect, while queued pre-connect subscriptions should not remain queued indefinitely.
Subscription messages to resubscribe
Hyperliquid WebSocket subscriptions are sent as JSON messages with the format:
{
"method": "subscribe",
"subscription": { "...": "..." }
}
Examples from the Hyperliquid WebSocket subscriptions documentation include:
Like what you're reading? Try it yourself — this link supports ChartedTrader at no cost to you.
Create a Hyperliquid account →
{
"method": "subscribe",
"subscription": {
"type": "allMids",
"dex": "<dex>"
}
}
{
"method": "subscribe",
"subscription": {
"type": "userEvents",
"user": "<address>"
}
}
{
"method": "subscribe",
"subscription": {
"type": "orderUpdates",
"user": "<address>"
}
}
{
"method": "subscribe",
"subscription": {
"type": "userFills",
"user": "<address>"
}
}
If your bot tracks local subscription state, make sure duplicate subscription acknowledgements or repeated stream messages do not cause double-counting.
Related reading
- Hyperliquid WebSocket Subscriptions: Message Formats, Types, and Examples
- Hyperliquid Websocket Reconnect Fix 2026
- Hyperliquid API Websocket Guide for Developers (2026)
Hyperliquid account link
This article contains a Hyperliquid referral link. If you sign up through Create a Hyperliquid account, I may earn a referral reward.
Continue with Hyperliquid
Browse the Hyperliquid guide hub for the complete user journey.
Silent disconnects in issue #340
Hyperliquid Python SDK issue #340 reports a related failure mode: after a WebSocket drop,WebsocketManager does not reconnect and does not signal the caller. The report says ws_ready remains True, the manager thread ends, existing subscriptions stop receiving messages, and a later subscribe() can raise WebSocketConnectionClosedException. The proposed root causes are that run() calls run_forever() with no reconnect delay, so the websocket-client default ends the read loop permanently; __init__ has no on_close/on_error handler to reset ws_ready; and on_open replays only queued_subscriptions, leaving already-active subscriptions unsent on a new connection.
The issue suggests passing a reconnect delay to run_forever(reconnect=...), adding on_close/on_error handlers that set ws_ready = False, and re-sending all active_subscriptions in on_open. This matters because bots depending on userFills, orderUpdates, or userEvents can miss fills or keep acting on stale order state after a network blip or server restart.
Issue #340 testnet reproduction and version details
Hyperliquid Python SDK issue #340 includes a testnet reproduction usingInfo with skip_ws=False, subscribing to allMids, then calling ws_manager.ws.close() to simulate a network drop. The report says that after 4 seconds ws_ready is still True, the manager thread is alive=False, keep_running=False, no further messages arrive, and a later subscribe() raises WebSocketConnectionClosedException.
The report points to websocket_manager.py:101-106 for run() calling self.ws.run_forever() with no arguments, which it says makes websocket-client use reconnect=None / RECONNECT = 0, ending the read loop permanently. It also points to websocket_manager.py:76-88 for missing on_close/on_error handlers and ws_ready never being reset, and to websocket_manager.py:141-145 for on_open replaying only queued_subscriptions.
The issue lists SDK version 0.24.0, commit 2fdb18f9517675ea03695a0962bd19eece9c83f0, and websocket-client 1.9.2. It also notes the report is related to issue #191 but adds the live testnet reproduction and the ws_ready / queued-subscription-only details.