nautechsystems/nautilus_trader · error · anyhow::Error

AX open-orders applied limit must be between 0 and {PAGE_SIZ

Error message

AX open-orders applied limit must be between 0 and {PAGE_SIZE}, was {}

What it means

A defensive check on a paginated open-orders response: the server-applied limit echoed in the page must lie in [0, PAGE_SIZE]. anyhow::ensure! fails the aggregation if AX claims to have applied a page size the client never requested, which would break the caller's offset/limit arithmetic. This signals an unexpected API response shape.

Source

Thrown at crates/adapters/architect_ax/src/http/client.rs:2002

                .context("AX open-orders offset exceeds the documented int32 range")?;
            let params = GetOpenOrdersParams {
                account_id: None,
                limit: Some(PAGE_SIZE),
                offset: Some(request_offset),
                sort_ts: Some("desc".to_string()),
            };
            let response = self
                .inner
                .get_open_orders_page(&params)
                .await
                .map_err(|e| anyhow::anyhow!(e))?;

            anyhow::ensure!(
                response.total_count >= 0,
                "AX open-orders total_count must be non-negative, was {}",
                response.total_count
            );
            anyhow::ensure!(
                response.limit >= 0 && response.limit <= PAGE_SIZE,
                "AX open-orders applied limit must be between 0 and {PAGE_SIZE}, was {}",
                response.limit
            );
            anyhow::ensure!(
                i64::from(response.offset) == offset,
                "AX open-orders response offset mismatch: requested {offset}, was {}",
                response.offset
            );

            let total_count = *expected_total.get_or_insert(response.total_count);
            anyhow::ensure!(
                response.total_count == total_count,
                "AX open-orders total_count changed during pagination: expected {total_count}, was {}",
                response.total_count
            );

            let page_len = i64::try_from(response.orders.len())

View on GitHub (pinned to 18893faf8b)

Solutions

1. Verify the AX API contract for the open-orders page's limit field and update the client if semantics changed.
2. Log/dump the raw response page to inspect the returned limit.
3. Ensure the client and the deployed AX API version are compatible.
4. Check for proxies/interceptors rewriting response bodies.

// validate the echoed page limit yourself
if response.limit < 0 || response.limit as usize > PAGE_SIZE {
    return Err(anyhow!("AX page limit {} outside [0, {PAGE_SIZE}]", response.limit));
}

match client.request_open_orders_paged().await {
    Ok(orders) => orders,
    Err(e) if e.to_string().contains("applied limit") => {
        tracing::error!("AX pagination semantics changed: {e:#}");
        Vec::new()
    }
    Err(e) => return Err(e),
};

When it happens

Trigger: Calling the paginated open-orders fetch when AX's response reports a limit that is negative or greater than the client's PAGE_SIZE — schema drift, response-field mismatch, or a gateway altering the payload.

Common situations: AX API upgrade changing the meaning or units of the limit field; responses from an incompatible AX environment (test vs prod) with different pagination semantics; mocked/stub responses used in local development.

Understand the failure class

Background: Schema validation failed / invalid input schema: payload rejected because its shape doesn't match the expected schema — this error's family across 28 libraries.

Related errors

• AX open-orders total_count must be non-negative, was {}
• AX open-orders response offset mismatch: requested {offset},
• Binance user-trades pagination made no progress
• Execution payload storage is marked ready without its write
• height must be positive, was {self.height}

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