nautechsystems/nautilus_trader · error

Cannot modify order in place: status is {status:?}, expected

Error message

Cannot modify order in place: status is {status:?}, expected INITIALIZED or RELEASED

What it means

modify_order_in_place only accepts orders in INITIALIZED or RELEASED status because in-place modification is only meaningful before the order has been submitted to or acted on by the venue. Orders in any other status (SUBMITTED, ACCEPTED, FILLED, DENIED, etc.) are rejected.

Source

Thrown at crates/trading/src/algorithm/mod.rs:1017

    ///
    /// # Errors
    ///
    /// Returns an error if the order status is not INITIALIZED or RELEASED,
    /// or if no parameters would change.
    fn modify_order_in_place(
        &mut self,
        order: &mut OrderAny,
        quantity: Option<Quantity>,
        price: Option<Price>,
        trigger_price: Option<Price>,
    ) -> anyhow::Result<()>
    where
        Self: ExecutionAlgorithmNative,
    {
        // Validate order status
        let status = order.status();
        if status != OrderStatus::Initialized && status != OrderStatus::Released {
            anyhow::bail!(
                "Cannot modify order in place: status is {status:?}, expected INITIALIZED or RELEASED"
            );
        }

        // Validate order type compatibility
        if price.is_some() && order.price().is_none() {
            anyhow::bail!(
                "Cannot modify order in place: {} orders do not have a LIMIT price",
                order.order_type()
            );
        }

        if trigger_price.is_some() && order.trigger_price().is_none() {
            anyhow::bail!(
                "Cannot modify order in place: {} orders do not have a STOP trigger price",
                order.order_type()
            );
        }

View on GitHub (pinned to 18893faf8b)

Solutions

1. Check order.status() is Initialized or Released before calling modify_order_in_place
2. Use the venue-level order modify request (generate_order_modify / OrderModify) for live orders
3. Guard against concurrent state changes by performing the check and modification in the same handler scope
4. Log order status on failure to diagnose races with submission

Example fix

// before
algo.modify_order_in_place(&mut order, Some(new_qty), None, None)?;
// after
if matches!(order.status(), OrderStatus::Initialized | OrderStatus::Released) {
    algo.modify_order_in_place(&mut order, Some(new_qty), None, None)?;
}

if !matches!(order.status(), OrderStatus::Initialized | OrderStatus::Released) { return Err(anyhow!("order not modifiable in place: {:?}", order.status())); }

fn modifiable_in_place(o: &OrderAny) -> bool { matches!(o.status(), OrderStatus::Initialized | OrderStatus::Released) }

match algo.modify_order_in_place(&mut order, q, p, t) { Err(e) if e.to_string().contains("status is") => { /* fall back to venue modify */ }, r => r?, }

When it happens

Trigger: Calling modify_order_in_place on an order already SUBMITTED/ACCEPTED at the venue, after it filled, or after it was canceled/denied.

Common situations: Race between an execution algorithm's modification logic and order submission; retrying a modification after the order state advanced; using modify-in-place where a venue-level order modify (OrderModify) is required instead.

Understand the failure class

Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.

Related errors

• Cannot modify order in place: {} orders do not have a LIMIT
• Cannot modify order in place: {} orders do not have a STOP t
• {FAILED}: {e}
• {FAILED}: {e}
• {FAILED}: {e}

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