provider venue order {} does not match requested venue order

Error message

provider venue order {} does not match requested venue order {venue_order_id}

What it means

When building an order report for a specific target venue order, the adapter asserts that the provider order row it received is actually the requested venue order id. This error means the venue/API returned a row for a different order id than the one requested, i.e. an internal lookup/identity inconsistency during reconciliation.

Source

Thrown at crates/adapters/polymarket/src/execution/reconciliation.rs:586

}

fn build_order_report_from_order(
    order: &PolymarketOpenOrder,
    instruments: &AtomicMap<Ustr, InstrumentAny>,
    ctx: &FillContext<'_>,
    scope: OrderEvidenceScope<'_>,
    ts_init: UnixNanos,
    load_ids: Option<&[InstrumentId]>,
) -> anyhow::Result<OrderRowResult> {
    let collection_load_ids = match scope {
        OrderEvidenceScope::Collection {
            instrument_filter: None,
        } => load_ids,
        _ => None,
    };

    if let OrderEvidenceScope::Target { venue_order_id, .. } = scope {
        anyhow::ensure!(
            order.id == venue_order_id.as_str(),
            "provider venue order {} does not match requested venue order {venue_order_id}",
            order.id,
        );
    }

    if !is_owned_by_account(
        &order.maker_address,
        &order.owner,
        ctx.user_address,
        ctx.api_key,
    ) {
        return match scope {
            OrderEvidenceScope::Collection { .. } => {
                log::debug!("Dropping open order {} not owned by the account", order.id);
                Ok(OrderRowResult {
                    report: None,
                    counted_filtered: true,

View on GitHub (pinned to 18893faf8b)

Solutions

Verify the venue_order_id passed to the reconciliation/request matches exactly the Polymarket order id (string equality, no whitespace/case differences).
Re-fetch the single order by id from the provider instead of scanning a list, ensuring the request filters on the exact id.
Check that client-to-venue order id mapping is stable across restarts and adapter versions.
If the provider consistently returns the wrong row, report the mismatch with both ids; the row is unusable for this target.

Example fix

// before: finding the order in a list by market instead of exact id
let order = orders.iter().find(|o| o.market == market)?;
// after: match on the exact venue order id
let order = orders.into_iter().find(|o| o.id == venue_order_id.as_str())
    .with_context(|| format!("order {venue_order_id} not in provider rows"))?;

Defensive patterns

Strategy: validation

Validate before calling

let order = client.get_order(&venue_order_id).await?;
if order.id != venue_order_id.as_str() {
    return Err(anyhow!("provider returned {} for requested {venue_order_id}", order.id));
}

Type guard

fn is_target_row(order: &PolymarketOpenOrder, wanted: &VenueOrderId) -> bool {
    order.id == wanted.as_str()
}

Try / catch

match result {
    Err(e) if e.to_string().contains("does not match requested venue order") => {
        log::error!("venue row identity mismatch; re-fetch order by exact id");
        reconcile_by_exact_id(&venue_order_id).await?;
    }
    other => other?,
}

Prevention

Pass venue order ids exactly as produced by the venue (no trimming/casing).
Fetch single orders by exact id rather than filtering lists by market/asset.
Maintain a stable client_order_id -> venue_order_id mapping in persistent storage.

When it happens

Trigger: Calling build_target_order_report (via order status report generation for a specific VenueOrderId) when the resolved `PolymarketOpenOrder.id` does not equal `scope.venue_order_id`. Happens if the provider lookup keyed on something other than the exact order id (e.g. hash/market+asset lookup returning the wrong row) or if the caller passes an incorrect venue_order_id.

Common situations: Multiple open orders on the same market token and the API list filtered imprecisely; venue_order_id formatting differences (checksum vs raw id, case); a custom strategy translating client order ids to venue ids incorrectly; adapter version changes in how order ids are derived from Polymarket's order hash.

Related errors

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