What causes "Failed to send order accepted event: {e}" in nautechsystems/nautilus_trader?

Inspect the inner {e} channel error to identify receiver-dropped vs backpressure.

nautechsystems/nautilus_trader · error · anyhow::Error

Failed to send order accepted event: {e}

Error message

Failed to send order accepted event: {e}

What it means

emit_order_accepted sends an OrderAccepted event through exec_sender once the adapter has confirmed the IB order was accepted, then sets context.accepted = true. This error is the map_err on the channel send — the accepted event could not be delivered, so strategy/execution state machines will not advance even though IB accepted the order.

Source

Thrown at crates/adapters/interactive_brokers/src/execution/core_tracking.rs:322

        if context.accepted {
            return Ok(false);
        }

        let event = OrderAccepted::new(
            context.trader_id,
            context.strategy_id,
            context.instrument_id,
            context.client_order_id,
            venue_order_id,
            account_id,
            UUID4::new(),
            ts_event,
            ts_event,
            false,
        );
        exec_sender
            .send(ExecutionEvent::Order(OrderEventAny::Accepted(event)))
            .map_err(|e| anyhow::anyhow!("Failed to send order accepted event: {e}"))?;
        context.accepted = true;

        Ok(true)
    }

    #[allow(clippy::too_many_arguments)]
    pub(super) fn remove_order_tracking(
        ib_order_id: i32,
        client_order_id: ClientOrderId,
        order_id_map: &Arc<Mutex<AHashMap<ClientOrderId, i32>>>,
        venue_order_id_map: &Arc<Mutex<AHashMap<i32, ClientOrderId>>>,
        instrument_id_map: &Arc<Mutex<AHashMap<i32, InstrumentId>>>,
        trader_id_map: &Arc<Mutex<AHashMap<i32, TraderId>>>,
        strategy_id_map: &Arc<Mutex<AHashMap<i32, StrategyId>>>,
        active_order_contexts: &Arc<Mutex<AHashMap<i32, TrackedOrderContext>>>,
        terminal_order_contexts: &Arc<Mutex<FifoCacheMap<i32, TrackedOrderContext, 10_000>>>,
    ) {
        order_id_map.lock().remove(&client_order_id);

View on GitHub (pinned to 18893faf8b)

Solutions

Inspect the inner {e} channel error to identify receiver-dropped vs backpressure.
Keep the ExecutionEngine running until all in-flight orders reach a terminal state before shutdown.
Reconnect the execution client and reconcile open orders after a dropped acceptance.
Increase exec channel capacity or throttle order flow if saturation is the cause.

Defensive patterns

Strategy: try-catch

Validate before calling

assert!(!exec_sender.is_closed(), "exec channel receiver dropped before acceptance could be emitted");

Try / catch

if let Err(e) = exec_client.submit_order(cmd).await {
    if e.to_string().contains("Failed to send order accepted event") {
        // IB accepted the order but the event was lost: reconcile open orders
    }
}

Prevention

Delay node shutdown until in-flight orders are terminal.
Reconcile open orders with IB on startup/reconnect to recover lost acceptances.
Monitor and size exec event channels for expected throughput.

When it happens

Trigger: An order acceptance arriving (from IB order status callback) while the exec event channel receiver is dropped/closed/full — engine shutdown, disconnect, or bus misconfiguration.

Common situations: Stopping the trading node just as fill/acceptance messages arrive; MessageBus channel exhaustion during high order throughput; adapter lifecycle bugs dropping the receiver early.

Related errors

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