You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/concepts/live.md
+6-2Lines changed: 6 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -215,6 +215,8 @@ The execution engine reuses a single retry counter (`_recon_check_retries`) for
215
215
216
216
When the open-order loop exhausts its retries, the engine issues one targeted `GenerateOrderStatusReport` probe before applying a terminal state. If the venue returns the order, reconciliation proceeds and the retry counter resets automatically.
217
217
218
+
**Single-order query protection**: To prevent rate limit exhaustion when many orders need individual queries, the engine limits single-order queries per reconciliation cycle via `max_single_order_queries_per_cycle` (default: 10). When this limit is reached, remaining orders are deferred to the next cycle. Additionally, the engine adds a configurable delay (`single_order_query_delay_ms`, default: 100ms) between single-order queries to further prevent rate limiting. This ensures the system can handle scenarios where bulk queries fail for hundreds of orders without overwhelming the venue API.
219
+
218
220
Orders that age beyond `open_check_lookback_mins` rely on this targeted probe. Keep the lookback generous for venues with short history windows, and consider increasing `open_check_threshold_ms` if venue timestamps lag the local clock so recently updated orders are not marked missing prematurely.
219
221
220
222
This ensures the trading node maintains a consistent execution state even under unreliable conditions.
@@ -228,8 +230,10 @@ This ensures the trading node maintains a consistent execution state even under
228
230
|`open_check_open_only`| True | When enabled, only open orders are requested during checks; if disabled, full order history is fetched (resource-intensive). |
229
231
|`open_check_lookback_mins`| 60 min | Lookback window (minutes) for order status polling during continuous reconciliation. Only orders modified within this window are considered. |
230
232
|`open_check_threshold_ms`| 5,000 ms | Minimum time since the order's last cached event before open-order checks act on venue discrepancies (missing, mismatched status, etc.). |
231
-
|`open_check_missing_retries`| 5 retries | Maximum retries before resolving an order that is open in cache but not found at venue. Prevents false positives from race conditions. |
232
-
|`reconciliation_startup_delay_secs`| 10.0 s | Additional delay (seconds) applied *after* startup reconciliation completes before starting continuous reconciliation loop. Provides time for additional system stabilization. |
233
+
|`open_check_missing_retries`| 5 retries | Maximum retries before resolving an order that is open in cache but not found at venue. Prevents false positives from race conditions. |
234
+
|`max_single_order_queries_per_cycle`| 10 | Maximum number of single-order queries per reconciliation cycle. Prevents rate limit exhaustion when many orders fail bulk query checks. |
235
+
|`single_order_query_delay_ms`| 100 ms | Delay (milliseconds) between single-order queries to prevent rate limit exhaustion. |
236
+
|`reconciliation_startup_delay_secs`| 10.0 s | Additional delay (seconds) applied *after* startup reconciliation completes before starting continuous reconciliation loop. Provides time for additional system stabilization. |
233
237
|`own_books_audit_interval_secs`| None | Sets the interval (in seconds) between audits of own order books against public ones. Verifies synchronization and logs errors for inconsistencies. |
Copy file name to clipboardExpand all lines: docs/integrations/bitmex.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -368,7 +368,7 @@ Exceeding BitMEX rate limits returns HTTP 429 and may trigger temporary IP bans;
368
368
All requests automatically consume both the global burst bucket and the rolling minute bucket. Endpoints that have their own minute quota (e.g. `/api/v1/order`) also queue against that per-route key, so repeated calls with different parameters still share a single rate bucket.
369
369
370
370
:::info
371
-
For more details on rate limiting, see the official documentation: <https://www.bitmex.com/app/restAPI#Rate-Limits>.
371
+
For more details on rate limiting, see the [BitMEX API documentation on rate limits](https://www.bitmex.com/app/restAPI#Limits).
0 commit comments