nautechsystems/nautilus_trader · error · anyhow::Error

Unsupported OKX order type: {e}

Error message

Unsupported OKX order type: {e}

What it means

parse_order_status_report converts an OKX WebSocket order message into a Nautilus OrderStatusReport. For order types not handled by the special Trigger/FOK/IOC branches it falls back to `OKXOrderType::try_into(OrderType)`; when the OKX ordType value has no Nautilus OrderType mapping, the conversion fails and this error wraps it. It means the adapter received (or the tests fed) an OKX order type the adapter does not yet support.

Source

Thrown at crates/adapters/okx/src/websocket/parse.rs:1754

    let order_type = match okx_order_type {
        OKXOrderType::Trigger => {
            if is_market_price(&msg.px) {
                OrderType::StopMarket
            } else {
                OrderType::StopLimit
            }
        }
        OKXOrderType::Fok | OKXOrderType::Ioc | OKXOrderType::OptimalLimitIoc => {
            determine_order_type_with_alt(
                okx_order_type,
                &msg.px,
                msg.px_vol.as_deref().unwrap_or(""),
                msg.px_usd.as_deref().unwrap_or(""),
            )?
        }
        other => other
            .try_into()
            .map_err(|e| anyhow::anyhow!("Unsupported OKX order type: {e}"))?,
    };
    let order_status: OrderStatus = msg
        .state
        .try_into()
        .map_err(|e| anyhow::anyhow!("Unsupported OKX order status: {e}"))?;

    let time_in_force = match okx_order_type {
        OKXOrderType::Fok | OKXOrderType::OpFok => TimeInForce::Fok,
        OKXOrderType::Ioc | OKXOrderType::OptimalLimitIoc => TimeInForce::Ioc,
        _ => TimeInForce::Gtc,
    };

    let size_precision = instrument.size_precision();

    // Parse quantities based on target currency
    // OKX always returns acc_fill_sz in base currency, but sz depends on tgt_ccy

    // Determine if this is a quote-quantity order

View on GitHub (pinned to 18893faf8b)

Solutions

  1. Log/inspect the raw msg.ordType string to identify the unmapped OKX order type.
  2. Check the OKXOrderType enum and its TryInto<OrderType> impl in the okx adapter for a missing mapping; add the variant mapping if OKX introduced a new ordType.
  3. Update the okx adapter dependency / upgrade nautilus to a version that maps the new ordType.
  4. As a workaround, filter or cancel unsupported order types at the venue so their status updates never reach the parser.

Example fix

// before (parse.rs:1752)
other => other.try_into().map_err(|e| anyhow::anyhow!("Unsupported OKX order type: {e}"))?,

// after (add mapping in OKXOrderType TryInto<OrderType> impl)
OKXOrderType::NewVariant => Ok(OrderType::Limit), // map the newly added OKX ordType
// or, defensively:
other => other.try_into().map_err(|e| {
    tracing::error!(ord_type = %msg.ord_type, "Unsupported OKX order type: {e}");
    anyhow::anyhow!("Unsupported OKX order type: {e}")
})?,
Defensive patterns

Strategy: try-catch

Validate before calling

// Rust: validate ordType before relying on the report
fn is_supported_order_type(t: &OKXOrderType) -> bool {
    matches!(
        t,
        OKXOrderType::Limit
            | OKXOrderType::PostOnly
            | OKXOrderType::Fok
            | OKXOrderType::Ioc
            | OKXOrderType::Market
            | OKXOrderType::Trigger
            | OKXOrderType::OpFok
            | OKXOrderType::OptimalLimitIoc
    )
}

Type guard

fn supported_order_type(t: &OKXOrderType) -> Option<OrderType> {
    OrderType::try_from(*t).ok()
}

Try / catch

match parse_order_status_report(&msg, &instrument, account_id, ts_init) {
    Ok(report) => handle(report),
    Err(e) if e.to_string().contains("Unsupported OKX order type") => {
        tracing::warn!(ord_id = %msg.ord_id, "skipping order with unsupported type: {e:#}");
    }
    Err(e) => return Err(e),
}

Prevention

When it happens

Trigger: An order-status update (orders channel or order-message parse path) whose `ordType` deserialized to an OKXOrderType variant for which `TryInto<OrderType>` returns Err — i.e. any ordType outside the mapped set (limit, post_only, fok, ioc, trigger, optimal_limit_ioc handled paths). Also triggered directly by unit tests passing synthetic OKXOrderType values.

Common situations: OKX adds a new ordType value (API version change) that serde deserializes into an unmapped variant; a user places an order kind (e.g. TWAP/iceberg variants) through the OKX web UI or another client and nautilus receives its status updates; running a stale adapter against a newer OKX API.

Related errors

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