nautechsystems/nautilus_trader · error

Cannot handle command: {command:?}

Error message

Cannot handle command: {command:?}

What it means

The backtest exchange's latency-model helper computes submit/modify/cancel latencies for known TradingCommand variants and panics on anything else. The catch-all _ arm means a command kind (e.g. SubmitOrder variants not matched, or future command types) reached code that only models the listed commands. Note the DECLARED/USED metadata references unrelated bench files; the actual panic site is the backtest exchange's inflight-latency calculation.

Source

Thrown at crates/backtest/src/exchange.rs:858

                .push(InflightCommand::new(timestamp, counter, command));
        }
    }

    fn generate_inflight_command(&mut self, command: &TradingCommand) -> (UnixNanos, u32) {
        if let Some(latency_model) = &self.latency_model {
            let ts = match command {
                TradingCommand::SubmitOrder(_) | TradingCommand::SubmitOrderList(_) => {
                    command.ts_init() + latency_model.get_insert_latency()
                }
                TradingCommand::ModifyOrder(_) | TradingCommand::ModifyOrders(_) => {
                    command.ts_init() + latency_model.get_update_latency()
                }
                TradingCommand::CancelOrder(_)
                | TradingCommand::CancelOrders(_)
                | TradingCommand::CancelAllOrders(_) => {
                    command.ts_init() + latency_model.get_delete_latency()
                }
                _ => panic!("Cannot handle command: {command:?}"),
            };

            let counter = self
                .inflight_counter
                .entry(ts)
                .and_modify(|e| *e += 1)
                .or_insert(1);

            (ts, *counter)
        } else {
            panic!("Latency model should be initialized");
        }
    }

    /// Processes a single order book delta.
    ///
    /// # Errors
    ///

View on GitHub (pinned to 18893faf8b)

Solutions

1. Handle the missing TradingCommand variant explicitly in the match (assign appropriate submit/modify latency)
2. Update the backtest engine to cover all current TradingCommand variants
3. Check which command your strategy emits and whether it should be mapped to a supported variant
4. Replace the panic with a fallback/default latency if unknown commands should not abort the backtest

Example fix

// before
_ => panic!("Cannot handle command: {command:?}"),
// after
TradingCommand::SubmitOrder(_) => command.ts_init() + latency_model.get_submit_latency(),
TradingCommand::ModifyOrder(_) => command.ts_init() + latency_model.get_modify_latency(),

fn command_has_latency_model(c: &TradingCommand) -> bool {
    matches!(c, TradingCommand::SubmitOrder(_)
        | TradingCommand::SubmitOrders(_)
        | TradingCommand::ModifyOrder(_)
        | TradingCommand::CancelOrder(_)
        | TradingCommand::CancelOrders(_)
        | TradingCommand::CancelAllOrders(_))
}

When it happens

Trigger: Calling the latency-computation path in BacktestExchange with a TradingCommand not covered by the explicit Submit/Cancel match arms — typically an unhandled command variant added to the enum or passed through generically.

Common situations: Backtesting a strategy that issues a command type the exchange's latency modeler does not handle; core enum extended without updating backtest matching; a new adapter routes a novel command into the backtest engine.

Related errors

• Latency model should be initialized
• Execution client should be initialized
• Matching engine not found for instrument {order_instrument_i
• Matching engine not found for instrument {instrument_id}
• Time event accumulator sequence overflow

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