nautechsystems/nautilus_trader · error · anyhow::Error
Modify order failed
Error message
Modify order failed: {e} What it means
Raised when the HTTP/REST modify-order path fails after possible ambiguity — the adapter logs 'Ambiguous modify failure ... awaiting reconciliation' when it cannot confirm whether the modify took effect, and then bails with the underlying error. Unlike the WS path, this error leaves the order state uncertain until reconciliation runs.
Solutions
- Wait for reconciliation to establish the true order state before retrying blindly
- Check the wrapped {e} for the exchange error code and correct the modify parameters
- If the order state is unknown, query order status (by client_order_id) before deciding to cancel/replace
- Retry only idempotent-safe operations after confirming the order is still open
- Check connectivity and clock skew if the error is a timeout
Example fix
// before
client.modify_order(...)?; // may be ambiguous
// after
if let Err(e) = client.modify_order(...) {
log::warn!("modify failed, reconciling: {e}");
let status = client.query_order_status(client_order_id)?;
// decide retry vs cancel/replace based on status
} Defensive patterns
Strategy: retry
Validate before calling
// verify order still open and parameters valid before HTTP modify
let status = client.query_order_status(client_order_id)?;
if status != OPEN { return Err(anyhow::anyhow!("order not open")); } Try / catch
if let Err(e) = client.modify_order(...) { log::warn!("ambiguous: {e}"); wait_for_reconciliation(); then_decide_retry_or_replace(); } Prevention
- Never retry blindly after an ambiguous modify failure
- Always reconcile order state after HTTP modify errors
- Prefer the WS modify path when available
When it happens
Trigger: Calling modify_order over the HTTP fallback with a rejected request or an ambiguous failure (timeout, disconnect after submit, unknown final state).
Common situations: Network interruption between request and response; exchange rejecting the modify (order filled/canceled); rate-limit or timestamp errors on the REST endpoint.
Related errors
- Binance Futures position request has unresolved instrument
- WS modify order failed
- account ID differs across fill group
- active Lighter order
- active Lighter order
AI-assisted analysis of nautechsystems/nautilus_trader@18893faf8b (2026-09-08).
Data as JSON: /api/errors/0a6ae3ec19659690.
Report an issue: GitHub.
Appendix: source
Thrown at crates/adapters/binance/src/futures/execution.rs:3459
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 18893faf8b)