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 theView on GitHub (pinned to 18893faf8b)
Solutions
- Align the Venue configured on the adapter with the venue the broker adapter stamps into its mass status.
- Check environment configs (testnet/mainnet/sim) so the same venue naming is used everywhere.
- Ensure each venue's client is registered with its own correct ExecutionClientConfig in the engine.
- 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
- Use consistent venue naming (including live/testnet/sim suffixes) across all configs.
- Register one execution client per venue with its own dedicated config.
- Diff venue identifiers between engine config and broker adapter output at startup.
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
- Execution mass status client ID {} did not match source clie
- Execution mass status account ID {} did not match source acc
- in-flight mutex poisoned
- IncompleteOrderReports { reports, detail: detail.into() }
- std::mem::take(&mut self.shutdown_errors).join("; ")
AI-assisted analysis of nautechsystems/nautilus_trader@18893faf8b (2026-09-08).
Data as JSON: /api/errors/f4882356820f8b9c.
Report an issue: GitHub.