When a websocket reconnects with the wrong state
Posted: Sat Oct 31, 2026 2:21 pm
When a websocket reconnects with the wrong state
Web-based platforms and some API connections use websockets, a persistent link that streams data. After a drop, the client reconnects and tries to resume.
The trouble is state. During the gap, orders may have filled, positions may have changed, and prices have moved. If the client reconnects and shows the last known state without refreshing, the screen is wrong.
A trader sees a position that closed minutes ago, or doesn't see one that opened. Buttons act on stale information. Duplicate orders result.
Well-built clients re-synchronize after reconnecting, fetching the full account state. Poorly built ones don't, or do it incompletely.
The habit that guards against it is simple: after any visible disconnect, however brief, reload the platform or manually refresh the positions list before acting.
For automated systems, the same principle applies in code. After reconnecting, query the account for open orders and positions, and reconcile with the internal records before sending anything.
Most nasty surprises with APIs happen in the minutes after an outage, when the system believes it knows the state and doesn't.
What's the routine after a connection drop, before placing or managing any trade?
Web-based platforms and some API connections use websockets, a persistent link that streams data. After a drop, the client reconnects and tries to resume.
The trouble is state. During the gap, orders may have filled, positions may have changed, and prices have moved. If the client reconnects and shows the last known state without refreshing, the screen is wrong.
A trader sees a position that closed minutes ago, or doesn't see one that opened. Buttons act on stale information. Duplicate orders result.
Well-built clients re-synchronize after reconnecting, fetching the full account state. Poorly built ones don't, or do it incompletely.
The habit that guards against it is simple: after any visible disconnect, however brief, reload the platform or manually refresh the positions list before acting.
For automated systems, the same principle applies in code. After reconnecting, query the account for open orders and positions, and reconcile with the internal records before sending anything.
Most nasty surprises with APIs happen in the minutes after an outage, when the system believes it knows the state and doesn't.
What's the routine after a connection drop, before placing or managing any trade?