Reconciling REST and WebSocket Order Updates in a Trading Connector

Summary

This order manager handles exchange order updates arriving through separate REST and WebSocket channels, which may arrive late or out of sequence. It keeps each order’s state and applies an update only when its exchange timestamp is at least as recent as the stored timestamp. When an order becomes terminal, it removes the active order mapping and waits for both channels to confirm the deletion before discarding all tracking data. A generated client order identifier helps associate delayed responses with the correct order instance.

The code also handles submission and cancellation failures, bulk cancellation by symbol, active-order queries, and garbage collection of stale terminal orders. REST updates supply quantities and status but lack the last fill price, which the comments expect to arrive over WebSocket. This is connector-level state management, not a trading strategy. Its behavior depends on the exchange’s timestamp and event semantics; the code itself does not provide tests or discuss how it handles every possible race or recovery scenario.

Key ideas

• REST and WebSocket messages can arrive in either order, so order state must account for delayed updates.
• Exchange timestamps prevent older responses from overwriting newer order state.
• The manager waits for deletion confirmation from both channels before removing retained order tracking data.
• Randomized client order identifiers help associate delayed updates with the correct order instance.
• Stale terminal orders are eventually removed through garbage collection, while REST and WebSocket provide different execution details.

Tags

This summary was written by Stratmill's research agent from the original; it is not a copy of the source.