Lighter inactive-order lookup exceeded {MAX_RECONCILIATION_P

Error message

Lighter inactive-order lookup exceeded {MAX_RECONCILIATION_PAGES} pages

What it means

The inactive (historical) orders endpoint is paginated, and the lookup caps pagination at MAX_RECONCILIATION_PAGES to bound latency and API usage. Exceeding the cap aborts the lookup rather than scanning the venue's full order history.

Source

Thrown at crates/adapters/lighter/src/websocket/dispatch.rs:1906

    if let Some(order) = active_match {
        return finalize(order).map(Some);
    }

    if target_venue_index.is_none() {
        return Ok(None);
    }

    // Fall back to inactive orders (filled / canceled). Pagination is followed
    // because a single market can hold more than 200 historical inactive
    // orders for a long-running account.
    let mut cursor: Option<String> = None;
    let mut seen_cursors = AHashSet::new();
    let mut pages = 0_usize;

    loop {
        pages += 1;
        anyhow::ensure!(
            pages <= MAX_RECONCILIATION_PAGES,
            "Lighter inactive-order lookup exceeded {MAX_RECONCILIATION_PAGES} pages",
        );
        let query = Zeroizing::new(LighterAccountInactiveOrdersQuery {
            authorization: None,
            auth: Some(auth.clone()),
            account_index: credential.account_index(),
            market_id: Some(market_index),
            ask_filter: None,
            between_timestamps: None,
            cursor: cursor.clone(),
            limit: LIGHTER_REST_PAGE_SIZE,
        });
        let inactive = http_client
            .get_account_inactive_orders(&query)
            .await
            .context("failed to fetch Lighter inactive orders")?;

View on GitHub (pinned to 18893faf8b)

Solutions

Narrow the lookup using a venue_order_id or tighter query window so the target order is found in fewer pages.
Raise MAX_RECONCILIATION_PAGES if your account legitimately needs deeper history scans.
Query the order directly by order_index via the REST API instead of paginating history.

Example fix

// before: full-history walk
lookup_order(Some(&coid), None, ...)
// after: search with explicit venue order id
lookup_order(Some(&coid), Some(&venue_order_id), ...)

Defensive patterns

Strategy: fallback

Try / catch

match lookup { Err(e) if e.to_string().contains("exceeded") => { /* fall back to direct REST query by order_index */ }, r => r? }

Prevention

Query with a venue_order_id when available
Keep reconciliation order lookups recent (avoid deep history scans)
Tune MAX_RECONCILIATION_PAGES only if legitimately needed

When it happens

Trigger: Looking up an order that is not in active orders and whose history is deep enough that the pagination cursor walks more than MAX_RECONCILIATION_PAGES pages without finding it.

Common situations: High-frequency accounts with very large closed-order histories; searching for an old order with only a client_order_id; time-range filters absent, forcing full-history scans.

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

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