nautechsystems/nautilus_trader · error · anyhow::Error

{failure_prefix}; outcome is unknown after possible transmis

Error message

{failure_prefix}; outcome is unknown after possible transmission: {reason}

What it means

When submitting an order to Interactive Brokers fails in a way that makes it impossible to know whether the order actually reached the venue (an 'ambiguous' classification), the adapter aborts with this error rather than fabricating an outcome. The order state is deliberately left unknown so the caller can reconcile with the broker instead of assuming rejected or accepted. It is raised inside handle_order_submit_failure after classify_order_submit_error returns CommandFailure::Ambiguous.

Source

Thrown at crates/adapters/interactive_brokers/src/execution/core_orders.rs:575

    pub(super) fn handle_order_submit_failure(
        error: &ibapi::Error,
        failure_prefix: &str,
        ib_order_id: i32,
        account_id: AccountId,
        ts_event: UnixNanos,
        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>>>,
        exec_sender: &tokio::sync::mpsc::UnboundedSender<ExecutionEvent>,
        clock: &'static AtomicTime,
    ) -> anyhow::Result<()> {
        match Self::classify_order_submit_error(error) {
            CommandFailure::Ambiguous(reason) => {
                anyhow::bail!(
                    "{failure_prefix}; outcome is unknown after possible transmission: {reason}"
                );
            }
            CommandFailure::NotSent(reason) | CommandFailure::VenueRejected(reason) => {
                let context = Self::get_tracked_order_context(
                    ib_order_id,
                    active_order_contexts,
                    terminal_order_contexts,
                )
                .with_context(|| format!("Tracked order context not found for {ib_order_id}"))?;

                Self::remove_order_tracking(
                    ib_order_id,
                    context.client_order_id,
                    order_id_map,
                    venue_order_id_map,
                    instrument_id_map,
                    trader_id_map,

View on GitHub (pinned to 18893faf8b)

Solutions

Treat the order outcome as unknown: query open orders / executions via reqOpenOrders or reqAllOpenOrders to reconcile the order's actual state before resubmitting.
Use a client order ID / idempotency key so a safe retry does not duplicate the order.
Inspect the failure_prefix and reason logged with the error to identify which transport failure occurred and address the connectivity issue.
Retry the submit only after confirming via the IB API that no matching order is live.

Example fix

// before: blindly resubmitting on any error
match submit_order(order) {
    Err(e) => { submit_order(order)?; }
    ...
}
// after: reconcile first when the outcome is ambiguous
match submit_order(order) {
    Err(e) if is_ambiguous_outcome(&e) => {
        reconcile_order_state(ib_order_id)?; // check open orders/executions
    }
    Err(e) => handle_order_submit_failure(...)?,
    Ok(_) => {}
}

Defensive patterns

Strategy: try-catch

Validate before calling

// Before resubmitting, check current open orders via the IB client
async fn order_maybe_live(client: &IBClient, ib_order_id: i32) -> bool {
    client.req_open_orders().await
        .iter().any(|o| o.order_id == ib_order_id)
}

Try / catch

match handle_order_submit_failure(...) {
    Err(e) if e.to_string().contains("outcome is unknown after possible transmission") => {
        // do NOT assume rejected; reconcile with broker state first
        reconcile_order_state(ib_order_id).await?;
    }
    Err(e) => return Err(e),
    Ok(()) => {}
}

Prevention

Maintain idempotent client order IDs so retries are safe
Monitor client/IB Gateway connectivity and fail fast on transport loss
Always reconcile ambiguous submissions against open orders/executions before retrying
Alert on this error rather than auto-resubmitting

When it happens

Trigger: A order submit returns an error that classify_order_submit_error maps to CommandFailure::Ambiguous(reason) — e.g. the request was sent but the response was lost or indeterminate (timeout after send, connection drop mid-request), so transmission may or may not have occurred.

Common situations: Network interruptions between the TWS/IB Gateway client and the venue, IB Gateway restarts mid-submit, client timeouts that fire after the request was already written to the socket.

Related errors

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