nautechsystems/nautilus_trader · error · anyhow::Error
WS submit order failed
Error message
WS submit order failed: {e} What it means
Thrown when a Binance Spot order submission over the User Data websocket API stream fails (the WS API request returned an error or the request errored). The code logs a warning that the client order id will be awaited via reconciliation and removes the pending request, then bails so the calling execution layer reports a denied/rejected submit.
Solutions
- Inspect the inner error `e` (logged as 'WS submit request failed for {client_order_id}') for the Binance error code and fix the order parameters or credentials
- Wait for reconciliation: the adapter intentionally leaves the order to be reconciled, so check subsequent order status reports before resubmitting to avoid duplicates
- Verify WS API connectivity/keys; fall back to the HTTP submission path if WS is unstable
- Retry the submit once order state is confirmed reconciled
Defensive patterns
Strategy: retry
Try / catch
match client.submit_order(&order).await {
Ok(()) => {},
Err(e) => {
log::warn!("submit failed: {e}; awaiting reconciliation before retry");
// do NOT resubmit immediately; wait for order status events
}
} Prevention
- Validate order price/qty against instrument filters before submit
- Keep API keys and clock skew healthy to avoid signature errors
- Monitor WS connection health and reconnect before trading
- Always reconcile via order status events before retrying a failed WS submit
When it happens
Trigger: `submit_order_internal` sends a place-order request over the WebSocket API and the awaited response yields `Err(e)` — e.g. Binance returns an error code (insufficient balance, invalid symbol/lot size, signature failure), the request times out, or the WS connection drops mid-request.
Common situations: Trading with use_ws_api-style WS order entry during network instability; placing orders with a misconfigured quantity/price filter; expired or wrong API keys producing -1022/-2015 errors over WS.
Understand the failure class
Background: "API request failed": what wrapped HTTP errors from external APIs mean and how to find the real cause — this error's family across 29 libraries.
Related errors
- WS cancel order failed
- Binance Spot data teardown failed
- Binance Spot public JSON stream pool is shutting down
- Buffer too short for SBE header: expected
- {errors.join("; ")}
AI-assisted analysis of nautechsystems/nautilus_trader@18893faf8b (2026-09-08).
Data as JSON: /api/errors/a544c3a151cea9d6.
Report an issue: GitHub.
Appendix: source
Thrown at crates/adapters/binance/src/spot/execution.rs:403
dispatch_state.pending_requests.insert(
request_id.clone(),
PendingRequest {
client_order_id,
venue_order_id: None,
operation: PendingOperation::Place,
},
);
self.spawn_task("submit_order_ws", async move {
if let Err(e) = ws_client
.place_order_with_id(request_id.clone(), params)
.await
{
dispatch_state.pending_requests.remove(&request_id);
log::warn!(
"WS submit request failed for {client_order_id}, awaiting reconciliation: {e}"
);
anyhow::bail!("WS submit order failed: {e}");
}
Ok(())
});
} else {
let http_client = self.http_client.clone();
let dispatch_state = self.dispatch_state.clone();
log::debug!("WS trading not active, falling back to HTTP for submit_order");
self.spawn_task("submit_order_http", async move {
let result = http_client
.submit_order(
account_id,
instrument_id,
client_order_id,
order_side,
order_type,
quantity,
time_in_force,View on GitHub (pinned to 18893faf8b)