nautechsystems/nautilus_trader · error · anyhow::Error

AX fills page length {page_len} exceeds applied limit {limit

Error message

AX fills page length {page_len} exceeds applied limit {limit}

What it means

After validating the reported `limit`, the paginator checks that the number of fills actually returned in the page (`page_len`) does not exceed that applied limit. A page larger than the server's own declared limit means the server violated its paging contract, so the client aborts to avoid inconsistent pagination state.

Source

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

        loop {
            let response = self
                .inner
                .get_fills_page(&params)
                .await
                .map_err(|e| anyhow::anyhow!(e))?;
            let page_len = response.fills.len();

            anyhow::ensure!(
                page_len <= PAGE_SIZE as usize,
                "AX fills page length {page_len} exceeds requested limit {PAGE_SIZE}"
            );

            if let Some(limit) = response.limit {
                anyhow::ensure!(
                    (0..=PAGE_SIZE).contains(&limit),
                    "AX fills applied limit must be between 0 and {PAGE_SIZE}, was {limit}"
                );
                anyhow::ensure!(
                    page_len <= limit as usize,
                    "AX fills page length {page_len} exceeds applied limit {limit}"
                );
            }

            if let Some(total_count) = response.total_count {
                anyhow::ensure!(
                    total_count >= 0,
                    "AX fills total_count must be non-negative, was {total_count}"
                );

                if let Some(expected) = expected_total {
                    anyhow::ensure!(
                        total_count == expected,
                        "AX fills total_count changed during pagination: expected {expected}, was {total_count}"
                    );
                } else {
                    expected_total = Some(total_count);

View on GitHub (pinned to 18893faf8b)

Solutions

1. Log the raw page: compare fills.len() against response.limit to confirm the server over-returned.
2. Lower the requested limit and retry; if the server still over-returns, report a pagination bug to the AX backend team.
3. Check for a recent AX API version change and pin or upgrade the client accordingly.
4. If a proxy/cache is involved, bypass it and call the AX endpoint directly.

match client.paginate_fills(params).await {
    Ok(fills) => apply(fills),
    Err(e) if e.to_string().contains("exceeds applied limit") => {
        warn!("AX server over-returned page; retrying with smaller limit");
        retry_with_limit(params.limit.unwrap_or(PAGE_SIZE) / 2);
    }
    Err(e) => return Err(e),
}

When it happens

Trigger: An AX fills page response where `response.limit` is Some(n) but `response.fills.len()` > n — i.e. the server returned more rows per page than its declared applied limit.

Common situations: Server-side paging bug after a deployment; duplicate rows inflated the page; the server ignored the requested limit and returned a full unbounded batch while echoing a smaller limit.

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 fills applied limit must be between 0 and {PAGE_SIZE}, wa
• AX fills total_count must be non-negative, was {total_count}
• AX fills total_count changed during pagination: expected {ex
• AX fills pagination returned duplicate trade ID {}
• AX fills pagination returned more unique rows ({}) than tota

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