nautechsystems/nautilus_trader · warning · anyhow::Error

{e}

Error message

{e}

What it means

In the single-order status report path, BinanceOrderQueryParams is built with derive_builder and any build() error is re-wrapped as anyhow with only the builder's error string, so the surfaced message is whatever the builder produced. In the current code every field of BinanceOrderQueryParams is Option/defaulted (query.rs:272-286), which makes this a defensive path that should not fire in practice — if it does, the wrapped {e} names the unmet builder invariant (e.g. a missing required field added in a future version).

Source

Thrown at crates/adapters/binance/src/futures/execution.rs:1749

                    .parse::<i64>()
                    .context("failed to parse venue_order_id as numeric")
            })
            .transpose()?;
        let orig_client_order_id = cmd
            .client_order_id
            .map(|id| encode_broker_id(&id, BINANCE_NAUTILUS_FUTURES_BROKER_ID));

        let mut builder = BinanceOrderQueryParamsBuilder::default();
        builder.symbol(symbol);

        if let Some(oid) = order_id {
            builder.order_id(oid);
        }

        if let Some(ref coid) = orig_client_order_id {
            builder.orig_client_order_id(coid.clone());
        }
        let params = builder.build().map_err(|e| anyhow::anyhow!("{e}"))?;

        let (price_precision, size_precision) = self.get_instrument_precision(instrument_id);
        let ts_init = self.clock.get_time_ns();
        let algo_lookup = self.resolve_algo_lookup(cmd.client_order_id, cmd.params.as_ref());

        if algo_lookup == BinanceFuturesAlgoLookup::AlgoId {
            let algo_order = self
                .http_client
                .query_algo_order_with_history(
                    instrument_id,
                    cmd.client_order_id,
                    cmd.venue_order_id,
                )
                .await?;

            return match algo_order {
                Some(result) => Ok(Some(create_algo_order_status_report(
                    &result,

View on GitHub (pinned to a4b06ed870)

Solutions

1. Read the wrapped {e}: it names the exact missing/invalid field — supply it (symbol via format_binance_symbol, order_id or orig_client_order_id)
2. Ensure the queried order carries a venue_order_id or orig_client_order_id so the query is well-formed
3. If unreachable in your version, treat a hit as an adapter regression and report it with the error string

// Ensure the query is well-formed before requesting a report:
anyhow::ensure!(
    cmd.venue_order_id.is_some() || cmd.orig_client_order_id.is_some(),
    "single-order query needs venue_order_id or orig_client_order_id"
);
let _ = format_binance_symbol(&instrument_id); // symbol must format cleanly

When it happens

Trigger: generate_order_status_reports (mass status or single-order query) reaching builder.build() with fields that fail the builder's invariants — currently none exist, so a hit implies a version where symbol/order-id fields became required and were not set.

Common situations: Upgrading the adapter to a version that adds required fields to the query params structs while calling code constructs the builder manually; custom forks adding validation to these builders.

Related errors

• Binance historical bars require time aggregation
• invalid Binance Futures order-book depth {depth}; valid valu
• Binance Futures ticker custom data requires BINANCE venue in
• BinanceFuturesExecutionClient requires UsdM or CoinM product
• Binance Futures account state request failed: {e}

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