nautechsystems/nautilus_trader · error

Execution mass status venue {} did not match source venue {}

Error message

Execution mass status venue {} did not match source venue {}

What it means

The execution client adapter also checks that the ExecutionMassStatus venue equals the adapter's own venue. A mismatch means the mass status describes orders on a different venue than this client source, so it cannot be used for reconciliation against this client's state.

Source

Thrown at crates/execution/src/client/mod.rs:183

        &self,
        lookback_mins: Option<u64>,
    ) -> anyhow::Result<Option<ExecutionMassStatus>> {
        let mass_status = self.client.generate_mass_status(lookback_mins).await?;

        if let Some(mass_status) = &mass_status {
            anyhow::ensure!(
                mass_status.client_id == self.client_id,
                "Execution mass status client ID {} did not match source client {}",
                mass_status.client_id,
                self.client_id,
            );
            anyhow::ensure!(
                mass_status.account_id == self.account_id,
                "Execution mass status account ID {} did not match source account {}",
                mass_status.account_id,
                self.account_id,
            );
            anyhow::ensure!(
                mass_status.venue == self.venue,
                "Execution mass status venue {} did not match source venue {}",
                mass_status.venue,
                self.venue,
            );
        }

        Ok(mass_status)
    }

    /// Forwards an instrument update to the underlying execution client.
    pub fn on_instrument(&mut self, instrument: InstrumentAny) {
        self.client.on_instrument(instrument);
    }

    /// Registers an external order for tracking by the execution client.
    ///
    /// This is called after reconciliation creates an external order, allowing the

View on GitHub (pinned to 18893faf8b)

Solutions

  1. Align the Venue configured on the adapter with the venue the broker adapter stamps into its mass status.
  2. Check environment configs (testnet/mainnet/sim) so the same venue naming is used everywhere.
  3. Ensure each venue's client is registered with its own correct ExecutionClientConfig in the engine.
  4. Log both venue values to identify which configuration side is wrong.
Defensive patterns

Strategy: validation

Validate before calling

// ensure each venue's client is registered under the matching Venue
assert_eq!(config.venue, adapter.venue(), "venue misrouting in execution config");

Try / catch

if let Err(e) = client.generate_mass_status(lookback).await {
    if e.to_string().contains("did not match source venue") {
        // correct the venue naming/env config, then retry
    }
}

Prevention

When it happens

Trigger: Calling generate_mass_status(lookback_mins) when the returned mass_status.venue differs from self.venue (after client_id and account_id checks passed).

Common situations: Adapter registered under one Venue but the underlying client reports another (e.g. testnet vs mainnet venue suffix, or SIM vs live); misrouted client registration in the execution engine config; copied adapter configs across venues.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors


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