nautechsystems/nautilus_trader · error · anyhow::Error

AX open-orders pagination did not return the advertised numb

Error message

AX open-orders pagination did not return the advertised number of unique orders

What it means

Final consistency check of the open-orders pagination: the number of unique collected orders must equal the total_count advertised on the first page (or 0 if no page was fetched). Any shortfall or surplus means the snapshot is incomplete or the server miscounted, so the client errors instead of returning partial data.

Source

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

            );

            for order in response.orders {
                anyhow::ensure!(
                    seen_order_ids.insert(order.oid.clone()),
                    "AX open-orders pagination returned duplicate order ID {}",
                    order.oid
                );
                orders.push(order);
            }

            if next_offset == total_count {
                break;
            }

            offset = next_offset;
        }

        anyhow::ensure!(
            i64::try_from(orders.len()).context("AX open-orders result length exceeds i64")?
                == expected_total.unwrap_or_default(),
            "AX open-orders pagination did not return the advertised number of unique orders"
        );

        let ts_init = self.generate_ts_init();
        let mut reports = Vec::with_capacity(orders.len());

        for order in &orders {
            let instrument = self.resolve_report_instrument(order.s).await?;

            match parse_order_status_report(
                order,
                account_id,
                &instrument,
                ts_init,
                cid_resolver.as_ref(),
            ) {

View on GitHub (pinned to 18893faf8b)

Solutions

1. Retry the whole pagination loop to get a matching snapshot
2. Poll during lower activity or increase page size to reduce pages needed
3. Compare raw page counts vs total to determine whether server totals or rows are wrong
4. Report persistent mismatches to the venue/adapter maintainers

if unique_orders.len() as i64 != advertised_total {
    return Err(anyhow!("snapshot mismatch: {} unique vs {} advertised",
        unique_orders.len(), advertised_total));
}

match result {
    Err(e) if e.to_string().contains("did not return the advertised number") => {
        warn!("AX snapshot inconsistent; retrying full pagination");
        restart_pagination()
    }
    other => other,
}

When it happens

Trigger: After all pages are consumed, orders.len() != expected_total — e.g. rows vanished mid-pagination, totals were inflated, or dedup removed repeats.

Common situations: High-churn accounts where orders fill/cancel during the poll; venue total_count computed at a different instant than row serving; adapter/venue API drift.

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/43ffca97266dc42d. Report an issue: GitHub.