nautechsystems/nautilus_trader · error · anyhow::Error

AX fills page length {page_len} exceeds requested limit {PAG

Error message

AX fills page length {page_len} exceeds requested limit {PAGE_SIZE}

What it means

The fills paginator requests a fixed PAGE_SIZE per call and asserts no page contains more rows than it asked for. A larger page means the server ignored or misapplied the limit, breaking the caller's batching assumptions and potentially returning oversized payloads.

Source

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

        let start_ns = start.map_or(floor_ns, |s| s.as_i64().max(floor_ns));
        let mut params = GetFillsParams::new(start_ns, end_ns);
        params.limit = Some(PAGE_SIZE);
        params.sort_ts = Some("desc".to_string());

        let mut fills = Vec::new();
        let mut seen_trade_ids = HashSet::new();
        let mut seen_cursors = HashSet::new();
        let mut expected_total = None;

        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,

View on GitHub (pinned to 18893faf8b)

Solutions

1. Check whether the limit query parameter is actually transmitted and named per current AX docs
2. Update the adapter for any API limit-semantics change
3. Truncate pages to PAGE_SIZE client-side only if you can prove rows beyond the limit are duplicates
4. Report limit-noncompliance to the venue/adapter maintainers

if page.fills.len() > PAGE_SIZE {
    return Err(anyhow!("server ignored limit: {} rows > {}",
        page.fills.len(), PAGE_SIZE));
}

fn respects_page_size(page_len: usize, page_size: usize) -> bool {
    page_len <= page_size
}

match result {
    Err(e) if e.to_string().contains("exceeds requested limit") => {
        error!("AX fills limit ignored by server; check API version/params");
        Err(e)
    }
    other => other,
}

When it happens

Trigger: A get_fills_page response contains more fill rows than the PAGE_SIZE the client requested, i.e. the server's limit handling changed or was ignored.

Common situations: AX API limit parameter regression or semantic change (e.g. limit interpreted as minimum); adapter/venue version drift; server ignoring limit when filters match many rows.

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 length {page_len} exceeds applied limit
• 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}

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