nautechsystems/nautilus_trader · error

Failed to fetch order status: {e}

Error message

Failed to fetch order status: {e}

What it means

Raised in `OrderSubmitter::get_order` (used by `check_fok_status`) when the retrying HTTP request to fetch an order's status from the Polymarket CLOB fails after retries. The error is invoked right after order submission to determine whether a FOK order was matched; a failure here leaves the order status unknown. The wrapped transport error is embedded in the message.

Source

Thrown at crates/adapters/polymarket/src/execution/submitter.rs:422

    ) -> anyhow::Result<Option<PolymarketOpenOrder>> {
        let http_client = self.http_client.clone();
        let oid = order_id.to_string();

        self.retry_manager
            .invocation(
                "get_order",
                || {
                    let http_client = http_client.clone();
                    let oid = oid.clone();
                    async move { http_client.get_order_optional(&oid).await }
                },
                |e| e.is_retryable(),
                |e| Error::transport(e.to_string()),
            )
            .retry_delay(&Error::retry_after)
            .execute()
            .await
            .map_err(|e| anyhow::anyhow!("Failed to fetch order status: {e}"))
    }

    /// Prepares multiple limit order submissions in parallel.
    pub(crate) async fn prepare_limit_order_submissions(
        &self,
        requests: &[LimitOrderSubmitRequest],
    ) -> Vec<anyhow::Result<SignedLimitOrderSubmission>> {
        let futures = requests
            .iter()
            .map(|request| self.prepare_limit_order_submission(request));
        futures_util::future::join_all(futures).await
    }

    pub(crate) async fn prepare_limit_order_submission(
        &self,
        request: &LimitOrderSubmitRequest,
    ) -> anyhow::Result<SignedLimitOrderSubmission> {
        let order_type = PolymarketOrderType::try_from(request.time_in_force)

View on GitHub (pinned to 18893faf8b)

Solutions

1. Retry with exponential backoff and honor any Retry-After header (the retry policy already keys off Error::retry_after)
2. Reduce status-poll frequency to stay under Polymarket rate limits
3. Confirm the venue_order_id/order id passed to get_order is correct
4. Inspect the inner error — if it is 404, the order id may be wrong or expired

match get_order(venue_order_id).await {
    Err(e) if e.is_retryable() => {
        tokio::time::sleep(retry_after_or_default()).await;
        // retry with cap
    }
    Err(e) => Err(anyhow!("order status unknown after retries: {e}")),
    Ok(status) => status,
}

When it happens

Trigger: Polling order status immediately after submitting a FOK order while the API is degraded or rate-limited (429); network interruption; the order id not yet queryable or not found on the venue.

Common situations: Tight FOK status-check loops that hit Polymarket rate limits; brief API downtime; container DNS flakes; clock/timing races where the order id is not yet indexed.

Understand the failure class

Background: 'Something went wrong' / 'Request failed (500)' / 'HTTP error! status: 404' — what failed HTTP requests actually mean and how to find the real cause — this error's family across 28 libraries.

Related errors

• Failed to probe market closure for {failed_chunks} of {total
• All {total} event slug requests failed
• Failed to fetch order book: {e}
• {e}
• Either client_order_id or venue_order_id is required

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