nautechsystems/nautilus_trader · critical · anyhow::Error

All {} requests failed: {:?}

Error message

All {} requests failed: {:?}

What it means

The BitMEX order submitter's broadcast_submit fan-out sent the submit request to the WebSocket broadcast pool, and every request in the batch returned an error. process_submit_results aggregates all per-request errors into a single anyhow error so the caller (broadcast_submit, which feeds Nautilus order emulators) sees one failure with the full error list.

Source

Thrown at crates/adapters/bitmex/src/broadcast/submitter.rs:658

            anyhow::bail!("IDEMPOTENT_DUPLICATE: Order likely exists but confirmation was lost");
        }

        if all_definitive_refusals && !errors.is_empty() {
            log::error!(
                "All {} requests were refused by BitMEX: {errors:?} {params}",
                operation.to_lowercase(),
            );
            anyhow::bail!(
                "{DEFINITIVE_SUBMIT_REJECTION}: All {} requests were refused by BitMEX: {errors:?}",
                operation.to_lowercase(),
            );
        }

        log::error!(
            "All {} requests failed: {errors:?} {params}",
            operation.to_lowercase(),
        );
        Err(anyhow::anyhow!(
            "All {} requests failed: {:?}",
            operation.to_lowercase(),
            errors
        ))
    }

    /// Broadcasts a submit request to all healthy clients in parallel.
    ///
    /// # Returns
    ///
    /// - `Ok(report)` if successfully submitted with a report.
    /// - `Err` if all requests failed.
    ///
    /// # Errors
    ///
    /// Returns an error if all submit requests fail or no healthy clients are available.
    #[expect(clippy::too_many_arguments)]
    pub async fn broadcast_submit(

View on GitHub (pinned to 18893faf8b)

Solutions

  1. Inspect the {:?} errors list in the message to see the per-request root cause (auth, timeout, exchange error) and fix that first
  2. Verify the WebSocket connection is healthy and credentials are valid before broadcasting
  3. Retry the submit once the connection is re-established; the failed batch was not applied if all requests errored
  4. Check BitMEX status/maintenance windows if errors are uniform connection failures
Defensive patterns

Strategy: try-catch

Validate before calling

// Rust: pre-flight checks before broadcast_submit
assert!(ws_client.is_connected(), "BitMEX WS not connected");
assert!(credentials_valid, "BitMEX credentials rejected");

Try / catch

match client.submit_order(order) {
    Ok(_) => {},
    Err(e) if e.to_string().contains("All") && e.to_string().contains("requests failed") => {
        log::error!("BitMEX submit batch failed entirely, check WS/auth: {e}");
        // reconnect and re-submit after confirming order was not applied
    }
    Err(e) => log::error!("submit error: {e}"),
}

Prevention

When it happens

Trigger: Calling submit/submit_order_list when the BitMEX WebSocket connection is down or the request pool times out; every in-flight request in the batch fails (auth rejection, disconnect, exchange error) so the errors vec has no successes to report.

Common situations: Network outage or BitMEX WS disconnect mid-session; invalid API credentials causing every request to be rejected; sending during exchange maintenance; all pooled broadcast channels saturated or closed.

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

AI-assisted analysis of nautechsystems/nautilus_trader@18893faf8b (2026-09-08). Data as JSON: /api/errors/97e185f9434aeaa6. Report an issue: GitHub.