What causes "WS cancel order failed: {e}" in nautechsystems/nautilus_trader?

Trigger/await reconciliation so the order's venue state is refreshed, then decide whether to re-cancel

nautechsystems/nautilus_trader · error · anyhow::Error

WS cancel order failed: {e}

Error message

WS cancel order failed: {e}

What it means

The WebSocket counterpart of cancel: when the WS order transport is active, cancel_order_with_id sends the cancel over the Binance Spot WS API. On failure the pending request id is removed, a warning about awaiting reconciliation is logged, and the spawned 'cancel_order_ws' task bails with this error — the order's cancellation state is unknown until reconciled.

Source

Thrown at crates/adapters/binance/src/spot/execution.rs:474

                request_id.clone(),
                PendingRequest {
                    client_order_id: command.client_order_id,
                    venue_order_id: command.venue_order_id,
                    operation: PendingOperation::Cancel,
                },
            );

            self.spawn_task("cancel_order_ws", async move {
                if let Err(e) = ws_client
                    .cancel_order_with_id(request_id.clone(), params)
                    .await
                {
                    dispatch_state.pending_requests.remove(&request_id);
                    log::warn!(
                        "WS cancel request failed for {}, awaiting reconciliation: {e}",
                        command.client_order_id
                    );
                    anyhow::bail!("WS cancel 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 cancel_order");

            self.spawn_task("cancel_order_http", async move {
                let result = http_client
                    .cancel_order(
                        command.instrument_id,
                        command.venue_order_id,
                        Some(command.client_order_id),
                    )
                    .await;

                match result {

View on GitHub (pinned to a4b06ed870)

Solutions

Trigger/await reconciliation so the order's venue state is refreshed, then decide whether to re-cancel
Retry the cancel with backoff once the WS session is healthy
Set use_ws_trading=false to send cancels over HTTP REST instead

Example fix

# before
config = BinanceExecClientConfig(use_ws_trading=True)  # WS cancel fails intermittently

# after: cancels over REST
config = BinanceExecClientConfig(use_ws_trading=False)

Defensive patterns

Strategy: retry

Try / catch

// on 'WS cancel order failed':
//   1. reconcile the order via order status reports
//   2. still open  -> re-send cancel after backoff
//   3. filled/gone -> adopt state, nothing to cancel
// never loop cancels without reconciling in between

Prevention

Space out cancel bursts to stay under WS rate limits
Reconcile before re-cancelling to avoid cancelling a re-filled order twice
Fall back to use_ws_trading=false (REST cancels) when WS reliability is poor

When it happens

Trigger: The WS cancel request fails inside the spawned task: session/logon errors, WS rate limits, disconnects, or the venue rejecting the cancel (e.g. order already filled) while the transport was still considered active.

Common situations: Cancel bursts hitting WS rate limits during volatile markets; session drops mid-cancel; orders that fill concurrently so the cancel arrives too late and surfaces as an error.

Related errors

AI-assisted analysis of nautechsystems/nautilus_trader@a4b06ed870 (2026-08-16). Data as JSON: /api/errors/acc380d8baf8e18e. Report an issue: GitHub.