nautechsystems/nautilus_trader · error

Unsupported OKX order type: {e}

Error message

Unsupported OKX order type: {e}

What it means

determine_order_type_with_alt maps OKX's order type string onto NautilusTrader's OrderType. Known strings are handled directly; any other string goes through TryInto<OrderType>, which rejects unrecognized OKX ordType values, and the failure is wrapped in this 'Unsupported OKX order type' anyhow error.

Source

Thrown at crates/adapters/okx/src/common/parse.rs:154

pub fn determine_order_type_with_alt(
    okx_ord_type: OKXOrderType,
    px: &str,
    px_vol: &str,
    px_usd: &str,
) -> anyhow::Result<OrderType> {
    match okx_ord_type {
        OKXOrderType::OpFok => Ok(OrderType::Limit),
        OKXOrderType::Fok | OKXOrderType::Ioc | OKXOrderType::OptimalLimitIoc => {
            let has_alt_price = !px_vol.is_empty() || !px_usd.is_empty();
            if has_alt_price || !is_market_price(px) {
                Ok(OrderType::Limit)
            } else {
                Ok(OrderType::Market)
            }
        }
        other => other
            .try_into()
            .map_err(|e| anyhow::anyhow!("Unsupported OKX order type: {e}")),
    }
}

/// Deserializes a string into `Option<OKXTargetCurrency>`, treating empty strings as `None`.
///
/// # Errors
///
/// Returns an error if the string cannot be parsed into an `OKXTargetCurrency`.
pub fn deserialize_target_currency_as_none<'de, D>(
    deserializer: D,
) -> Result<Option<OKXTargetCurrency>, D::Error>
where
    D: Deserializer<'de>,
{
    let s = String::deserialize(deserializer)?;
    if s.is_empty() {
        Ok(None)
    } else {

View on GitHub (pinned to 18893faf8b)

Solutions

1. Update the adapter/OKX enum definitions to the latest version so newly introduced ordType strings are recognized.
2. Log the raw ordType value that failed TryInto so you know exactly which string is missing from the mapping.
3. Extend the mapping (or the TryFrom impl for OrderType) to cover the new OKX ordType with the closest Nautilus OrderType.
4. As a stopgap, treat unknown types as skipped order reports with a warning rather than erroring the whole parse.

Example fix

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

// after
"trigger" => Ok(OrderType::StopMarket), // map newly seen OKX ordType explicitly
other => other
    .try_into()
    .map_err(|e| anyhow::anyhow!("Unsupported OKX order type: {e}")),

const KNOWN_OKX_ORDERTYPES: &[&str] = &["limit", "post_only", "fok", "ioc", "market", "optimal_limit_ioc"];
fn is_known_ord_type(t: &str) -> bool { KNOWN_OKX_ORDERTYPES.contains(&t) }

match determine_order_type(&report) {
    Ok(t) => t,
    Err(e) => { log::warn!("{} — skipping report", e); return Ok(None); }
}

When it happens

Trigger: determine_order_type or parse_order_status_report receives an OKX order whose ordType is not one of the recognized values (limit/post_only/fok/ioc/market/optimal_limit_ioc etc.) — e.g. a new or algo order type string OKX introduced or an algo variant like 'trigger'/'move_order_stop' flowing through this path.

Common situations: OKX adds a new ordType in an API update while the adapter pins an older enum; using algo-order endpoints whose result types aren't handled; regional OKX deployments (e.g. OKX Jump Trading/derivatives variants) emitting extra type strings; stale adapter version after an exchange API change.

Related errors

• Lighter `{kind:?}` has no Nautilus order-type equivalent
• instrument update lock poisoned
• option_summary_family_subs mutex poisoned
• Conditional order types must use OKXAlgoOrderType
• Invalid `OrderType` cannot be represented on OKX: {value:?}

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