nautechsystems/nautilus_trader · error · anyhow::Error

Modify order failed: {e}

Error message

Modify order failed: {e}

What it means

The REST modify (PUT /fapi/v1/order or /dapi/v1/order) returned an error. The adapter distinguishes structured venue rejections (definitive Binance error codes), for which it emits an OrderModifyRejected event, from ambiguous transport failures where it logs 'Ambiguous modify failure ... awaiting reconciliation' because the modify may or may not have been applied; both paths then raise this error from the spawned task.

Source

Thrown at crates/adapters/binance/src/futures/execution.rs:2942

                            command.client_order_id,
                            format!("modify-order-failed: {e}").into(),
                            UUID4::new(),
                            ts_now,
                            ts_now,
                            false,
                            command.venue_order_id,
                            Some(account_id),
                        );

                        emitter.send_order_event(OrderEventAny::ModifyRejected(rejected));
                    } else {
                        log::warn!(
                            "Ambiguous modify failure for {}, awaiting reconciliation: {e}",
                            command.client_order_id
                        );
                    }

                    anyhow::bail!("Modify order failed: {e}");
                }
            }

            Ok(())
        });

        Ok(())
    }

    fn cancel_order(&self, cmd: CancelOrder) -> anyhow::Result<()> {
        self.cancel_order_internal(&cmd);
        Ok(())
    }

    fn cancel_all_orders(&self, cmd: CancelAllOrders) -> anyhow::Result<()> {
        let http_client = self.http_client.clone();
        let instrument_id = cmd.instrument_id;

View on GitHub (pinned to a4b06ed870)

Solutions

1. Read the appended {e}: Binance error codes pinpoint the cause (e.g. -2011 means the order is gone)
2. Re-query the order (QueryOrder) to learn its current state before re-modifying
3. Align price and quantity to the instrument's tick and step sizes from the instrument definitions
4. For ambiguous network failures, let reconciliation resolve state instead of blind re-submission

Consume OrderModifyRejected events for structured venue rejections (fix parameters, do not blind-retry); for ambiguous transport failures, re-query the order via QueryOrder and retry the modify only if it is still open.

When it happens

Trigger: ModifyOrder over HTTP fails: order already filled or canceled (-2011), the modification would immediately trigger the order, quantity/price violate tick or step size, rate limit exceeded, or a network timeout (ambiguous case).

Common situations: Racing a modify against a fill; prices/quantities not scaled to instrument precision; clock skew affecting recvWindow; IP rate limits during bursts of modifications.

Related errors

• WS modify order failed: {e}
• Either venue_order_id or client_order_id must be provided
• Invalid venue order ID
• failed to parse venue_order_id: {e}
• failed to build order query params: {e}

AI-assisted analysis of nautechsystems/nautilus_trader@a4b06ed870 (2026-08-16). Data as JSON: /api/errors/0a6ae3ec19659690. Report an issue: GitHub.