What causes "cannot replay order {} for inferred fill detection: {e}" in nautechsystems/nautilus_trader?

Verify the first event for the order is a valid order-initialized event in the event store/cache

nautechsystems/nautilus_trader · error · anyhow::Error

cannot replay order {} for inferred fill detection: {e}

Error message

cannot replay order {} for inferred fill detection: {e}

What it means

For inferred fill detection the manager replays an order's event history: it builds a fresh OrderAny from the first event and applies the rest. If constructing the order from the initial event fails (event order invalid, unsupported event type, corrupted state), the error is wrapped with this message naming the client_order_id.

Source

Thrown at crates/live/src/execution/manager.rs:2921

        anyhow::ensure!(
            !position.is_opposite_side(report.order_side) || report.last_qty <= position.quantity,
            "fill {} without a venue position ID would cross position {position_id}",
            report.trade_id,
        );

        report.venue_position_id = Some(position_id);
        Ok(PositionFillReportPreparation::Ready)
    }

    #[cfg(feature = "node")]
    fn has_active_inferred_fill(order: &OrderAny) -> anyhow::Result<bool> {
        let events = order.events();
        let trade_ids = order.trade_ids();
        let Some((first, remaining)) = events.split_first() else {
            return Ok(false);
        };
        let mut projected = OrderAny::from_events(vec![(*first).clone()]).map_err(|e| {
            anyhow::anyhow!(
                "cannot replay order {} for inferred fill detection: {e}",
                order.client_order_id(),
            )
        })?;

        for event in remaining {
            projected.apply((*event).clone()).map_err(|e| {
                anyhow::anyhow!(
                    "cannot replay order {} for inferred fill detection: {e}",
                    order.client_order_id(),
                )
            })?;
            let OrderEventAny::Filled(fill) = event else {
                continue;
            };

            if !fill.reconciliation || !trade_ids.contains(&&fill.trade_id) {
                continue;

View on GitHub (pinned to 18893faf8b)

Solutions

Verify the first event for the order is a valid order-initialized event in the event store/cache
Purge the corrupted order's events and re-reconcile the order from the venue
Check for nautilus version mismatches between what wrote the events and the running node
Fix any custom event-store serialization so event order and completeness are preserved

Example fix

// before (events fetched unsorted)
let events = store.load(client_order_id)?;
// after
let mut events = store.load(client_order_id)?;
events.sort_by_key(|e| e.ts_init());

Defensive patterns

Strategy: try-catch

Validate before calling

let events = order.events();
let ok = events.first().map_or(true, |e| matches!(e, OrderEventAny::Initialized(_)));

Type guard

fn first_event_initializes(events: &[OrderEventAny]) -> bool {
    matches!(events.first(), Some(OrderEventAny::Initialized(_)))
}

Try / catch

match result {
    Err(e) if e.to_string().contains("cannot replay order") => {
        // mark order's cache entry corrupt and reconcile from venue
    }
    other => other?,
}

Prevention

Store order events atomically and in ts_init order
Keep the nautilus version that reads the event store compatible with the one that wrote it
Never persist adapter events that bypass order initialization

When it happens

Trigger: OrderAny::from_events(first_event) returns Err while running inferred-fill detection on a cached order - e.g. the first event is not a valid initializing event, events were persisted out of order, or an event from an incompatible version cannot rebuild state.

Common situations: Cache/event-store containing events written by a different nautilus version; events truncated or reordered by a custom event store; adapter-emitted events that skip required initialization; corrupted Redis/Postgres cache snapshots.

Understand the failure class

Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.

Related errors

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