nautechsystems/nautilus_trader · error · anyhow::Error

AX open-orders page length {page_len} exceeds applied limit

Error message

AX open-orders page length {page_len} exceeds applied limit {}

What it means

The AX API returned more order rows in a single page than the limit parameter that was applied to the request. The client validates that the server honors the requested page size before advancing the offset; a longer page would make offset arithmetic incorrect and silently skip or duplicate orders.

Source

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

                "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())
                .context("AX open-orders page length exceeds i64")?;
            anyhow::ensure!(
                page_len <= i64::from(response.limit),
                "AX open-orders page length {page_len} exceeds applied limit {}",
                response.limit
            );
            let next_offset = offset
                .checked_add(page_len)
                .context("AX open-orders offset overflow")?;
            anyhow::ensure!(
                next_offset <= total_count,
                "AX open-orders page exceeds total_count: next offset {next_offset}, total {total_count}"
            );

            if total_count == 0 {
                anyhow::ensure!(
                    response.orders.is_empty(),
                    "AX open-orders returned rows with total_count zero"
                );
                break;

View on GitHub (pinned to 18893faf8b)

Solutions

1. Verify the limit parameter actually sent in the request matches what the API expects
2. Check for an AX API version change and update the adapter
3. Log the raw response and report the contract violation to the venue/adapter maintainers
4. Cap page consumption client-side to the requested limit as a defensive measure

if let Some(resp) = &last_response {
    assert!(resp.orders.len() <= resp.limit as usize,
        "server returned {} rows for limit {}", resp.orders.len(), resp.limit);
}

fn page_within_limit(page_len: usize, limit: i64) -> bool {
    page_len <= limit as usize
}

match result {
    Err(e) if e.to_string().contains("exceeds applied limit") => {
        log::error!("AX API limit semantics changed; verify adapter version");
        Err(e)
    }
    other => other,
}

When it happens

Trigger: A server-side bug, API version change, or misinterpreted limit parameter causes response.orders.len() to exceed response.limit on a page of the open-orders pagination.

Common situations: Adapter/venue version drift where limit semantics changed; proxy or gateway mangling query parameters; new API behavior not covered by the adapter's expectations.

Understand the failure class

Background: "invalid response format", "malformed payload", "missing data field": when an API returns 200 but the response shape is wrong — this error's family across 23 libraries.

Related errors

• AX open-orders total_count changed during pagination: expect
• AX open-orders page exceeds total_count: next offset {next_o
• AX open-orders returned rows with total_count zero
• AX open-orders returned an empty page before offset {offset}
• AX open-orders pagination returned duplicate order ID {}

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