nautechsystems/nautilus_trader · error

{FAILED}: {e}

Error message

{FAILED}: {e}

What it means

This panic occurs in the constructor of a trailing stop market order (new) when the inner builder/constructor function returns an Err. The message wraps the underlying validation error text, prefixed with FAILED. It means the order parameters (prices, quantities, IDs, timestamps, etc.) failed domain validation, so the constructor aborts the process with a panic rather than returning a Result.

Source

Thrown at crates/model/src/orders/trailing_stop_market.rs:234

            time_in_force,
            expire_time,
            reduce_only,
            quote_quantity,
            display_qty,
            emulation_trigger,
            trigger_instrument_id,
            contingency_type,
            order_list_id,
            linked_order_ids,
            parent_order_id,
            exec_algorithm_id,
            exec_algorithm_params,
            exec_spawn_id,
            tags,
            init_id,
            ts_init,
        )
        .unwrap_or_else(|e| panic!("{FAILED}: {e}"))
    }

    #[must_use]
    pub fn has_activation_price(&self) -> bool {
        self.activation_price.is_some()
    }

    pub fn set_activated(&mut self) {
        debug_assert!(!self.is_activated, "double activation");
        self.is_activated = true;
    }
}

impl PartialEq for TrailingStopMarketOrder {
    fn eq(&self, other: &Self) -> bool {
        self.client_order_id == other.client_order_id
    }
}

View on GitHub (pinned to 18893faf8b)

Solutions

1. Inspect the wrapped {e} message to see which domain validation failed
2. Validate the price, quantity, instrument_id, activation_price and trailing offset against the instrument's precision/size rules before calling new
3. Ensure all identifier fields (trader_id, strategy_id, instrument_id, client_order_id) are valid and non-default
4. If constructing from external input, parse into Price/Quantity/Money types first so precision errors surface before order creation

Example fix

// before
let order = TrailingStopMarketOrder::new(/* unchecked raw values */).expect("valid");
// after
let quantity = Quantity::new(qty, instrument.size_precision())?;
let price = Price::new(trigger_px, instrument.price_precision())?;
let order = TrailingStopMarketOrder::new(/* validated Price/Quantity and IDs */)
    .unwrap_or_else(|e| log::error!("order creation failed: {e}"));

fn is_valid_order_input(instrument: &InstrumentAny, qty: f64, price: f64, activation: Option<f64>) -> bool {
    qty > 0.0
        && qty >= instrument.size_increment().as_f64()
        && (activation.is_none() || activation.unwrap() > 0.0)
        && price > 0.0
}

When it happens

Trigger: Calling TrailingStopMarketOrder::new (or its Python binding) with invalid parameters such as a non-positive quantity, malformed price strings, mismatched instrument/venue IDs, activation_price with no trailing offset, or any rule-violating field that makes the internal from_parts-style constructor return Err.

Common situations: Feeding unvalidated user or exchange data into order construction; passing strings with wrong precision for prices; supplying an init_id/ts_init of zero or invalid instrument_id; building orders from deserialized JSON with missing or malformed fields.

Related errors

• `close_position` cannot be combined with `reduce_only` on Bi
• in-flight mutex poisoned
• wallet balance mutex poisoned
• instrument update lock poisoned
• rate limiter decision lock poisoned

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