nautechsystems/nautilus_trader · error · anyhow::Error

AX fills applied limit must be between 0 and {PAGE_SIZE}, wa

Error message

AX fills applied limit must be between 0 and {PAGE_SIZE}, was {limit}

What it means

The AX fills paginator validates that the `limit` field the server reports in each page response is within the legal range 0..=PAGE_SIZE. If the server echoes a limit outside that range (negative or larger than the max page size), the client refuses to trust it and aborts the fetch. This protects the paginator from applying an unbounded or nonsensical page size while paging through fills.

Source

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

        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,
                    "AX fills total_count must be non-negative, was {total_count}"
                );

                if let Some(expected) = expected_total {
                    anyhow::ensure!(
                        total_count == expected,

View on GitHub (pinned to 18893faf8b)

Solutions

1. Inspect the raw AX fills HTTP response body and check the `limit` field the server actually returns.
2. Confirm the server honors the limit you requested and caps it at PAGE_SIZE; file a bug with the AX service if it echoes a larger value.
3. Re-run with a smaller, explicitly-requested limit (<= PAGE_SIZE) so the server's applied limit stays in range.
4. Update the client to a version whose PAGE_SIZE matches the server's maximum page size.

Example fix

// before: sending no explicit limit, letting server pick an out-of-range value
let page = client.fills(FillsParams { cursor, ..Default::default() }).await?;
// after: pin the limit to PAGE_SIZE so the applied limit cannot exceed it
let page = client.fills(FillsParams { limit: Some(PAGE_SIZE), cursor, ..Default::default() }).await?;

// request only legal limits up front
assert!((0..=PAGE_SIZE).contains(&params.limit.unwrap_or(PAGE_SIZE)), "limit out of range");

When it happens

Trigger: Calling the AX fills pagination client method (client.rs paginate_fills loop) when the server response contains `limit` set to a value < 0 or > PAGE_SIZE (the client's maximum page size).

Common situations: A backend upgrade or misbehaving AX endpoint returns an oversized echo of the requested limit; a proxy rewrites the limit field; the client's PAGE_SIZE constant was reduced in a client update while the server still returns the old larger limit.

Understand the failure class

Background: "value must be between 0 and 1" / "out of range" / "must not be negative" errors: fixing range-validation failures across open-source libraries — this error's family across 42 libraries.

Related errors

• AX fills page length {page_len} exceeds applied limit {limit
• 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/14ac3f093b05581e. Report an issue: GitHub.