nautechsystems/nautilus_trader · error

{reason}

Error message

{reason}

What it means

When modify_order receives a command it cannot honor, it emits a ModifyOrderRejected event to the engine and bails with the rejection reason itself as the message. The reason string comes from the caller's validation (e.g. unknown order, missing identifiers), so this error's text is entirely determined by that reason.

Source

Thrown at crates/adapters/deribit/src/execution.rs:1205

    }
}

fn reject_modify_command(
    emitter: &ExecutionEventEmitter,
    clock: &AtomicTime,
    cmd: &ModifyOrder,
    reason: &str,
) -> anyhow::Result<()> {
    let ts_event = clock.get_time_ns();
    emitter.emit_order_modify_rejected_event(
        cmd.strategy_id,
        cmd.instrument_id,
        cmd.client_order_id,
        cmd.venue_order_id,
        reason,
        ts_event,
    );
    anyhow::bail!("{reason}");
}

#[cfg(test)]
mod tests {
    use nautilus_common::messages::{ExecutionEvent, execution::ExecutionReport};
    use nautilus_core::UUID4;
    use nautilus_model::{
        enums::{LiquiditySide, OrderSide},
        events::OrderFilled,
        identifiers::{ClientOrderId, InstrumentId, StrategyId, TradeId, TraderId, VenueOrderId},
        types::{Currency, Money, Price, Quantity},
    };
    use rstest::rstest;

    use super::*;

    fn dispatch_test_rig() -> (
        ExecutionEventEmitter,

View on GitHub (pinned to 18893faf8b)

Solutions

1. Read the {reason} text — it states exactly why the modify was rejected
2. Ensure the order was submitted through this client so its venue_order_id is known
3. Do not attempt to modify orders after client restart without restoring order state
4. Guard upstream command construction so only orders with known venue state are modified

Example fix

// before
client.modify_order(&ModifyOrderCommand { client_order_id: unknown_id, ... }).await?;
// after
if let Some(venue_order_id) = client.venue_order_id_for(&unknown_id) {
    client.modify_order(&ModifyOrderCommand { client_order_id: unknown_id, venue_order_id, ... }).await?;
} else {
    log::warn!("skipping modify: no venue_order_id known for {unknown_id}");
}

// Ensure the order is known to this client before modifying
let known = client.venue_order_id_for(&cmd.client_order_id).is_some()
    || cmd.venue_order_id.is_some();
if !known {
    log::warn!("modify will be rejected: unknown order {}", cmd.client_order_id);
}

When it happens

Trigger: Calling modify_order with a command lacking a resolvable venue_order_id/order, or any condition the client validates upfront that produces a rejection reason passed into this code path.

Common situations: Modifying an order the client never submitted (no venue_order_id mapping); commands replayed after a restart losing order state; malformed modify commands constructed upstream.

Understand the failure class

Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.

Related errors

• invalid depth {depth}; supported depths: {DERIBIT_BOOK_VALID
• Modify order failed: {e}
• Cancel order failed: {e}
• Cancel all orders failed: {e}
• Batch cancel order failed: {e}

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