nautechsystems/nautilus_trader · error
{FAILED}: {e}
Error message
{FAILED}: {e} What it means
StopLimitOrder::new panics with `Condition failed: {e}` when StopLimitOrder::new_checked returns an OrderError; `new` unwraps into a panic. Checks include check_positive_quantity, check_display_qty, check_time_in_force (GTD requires expire_time) and OrderInitialized::new_checked invariants. `FAILED` is `"Condition failed"` from crates/core/src/correctness.rs.
Source
Thrown at crates/model/src/orders/stop_limit.rs:226
expire_time,
post_only,
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}"))
}
}
impl Deref for StopLimitOrder {
type Target = OrderCore;
fn deref(&self) -> &Self::Target {
&self.core
}
}
impl DerefMut for StopLimitOrder {
fn deref_mut(&mut self) -> &mut Self::Target {
&mut self.core
}
}
impl PartialEq for StopLimitOrder {
fn eq(&self, other: &Self) -> bool {View on GitHub (pinned to 18893faf8b)
Solutions
- Inspect the OrderError message in the panic for the precise violated check.
- Switch to StopLimitOrder::new_checked and handle the Result.
- Fix inputs: positive quantity, display_qty <= quantity, expire_time set for GTD, valid side.
- Validate values from strategy config before calling the constructor.
Example fix
// before let order = StopLimitOrder::new(..., TimeInForce::Gtd, None, ...); // panics // after let order = StopLimitOrder::new_checked(..., TimeInForce::Gtd, Some(expire_unix_nanos), ...)?;
Defensive patterns
Strategy: validation
Validate before calling
fn valid_sl_args(qty: Quantity, display_qty: Option<Quantity>, tif: TimeInForce, expire_time: Option<UnixNanos>) -> Result<(), String> {
if qty.raw == 0 { return Err("quantity must be positive".into()); }
if let Some(dq) = display_qty { if dq > qty { return Err("display_qty exceeds quantity".into()); } }
if tif == TimeInForce::Gtd && expire_time.map_or(true, |t| t.as_u64() == 0) { return Err("GTD requires expire_time".into()); }
Ok(())
} Type guard
if qty.is_zero() || side == OrderSide::NoOrderSide { return None; } Prevention
- Pair every GTD order with expire_time
- Keep display_qty <= quantity
- Check quantity positivity at config load
- Prefer new_checked where inputs may be invalid
When it happens
Trigger: Calling StopLimitOrder::new (crates/model/src/orders/stop_limit.rs) with a non-positive quantity, display_qty exceeding quantity, GTD without a valid expire_time, or an invalid init-event invariant (NoOrderSide, bad contingency/linked_order_ids combination).
Common situations: GTD stop-limit orders without expire_time; display_qty misconfigured above quantity; zero quantity from defaulted config; sides lost in enum conversion when bridging from Python or serialized events.
Related errors
AI-assisted analysis of nautechsystems/nautilus_trader@18893faf8b (2026-09-08).
Data as JSON: /api/errors/6f3f4c98d8d69b3f.
Report an issue: GitHub.