nautechsystems/nautilus_trader · error · anyhow::Error
Execution client {client_id} disappeared during startup reco
Error message
Execution client {client_id} disappeared during startup reconciliation What it means
After reconciling an execution client's mass status, the node re-checks that the client is still registered in the exec engine (anyhow::ensure! with get_client(&client_id).is_some()). If it vanished — for example a disconnect or adapter failure occurred while reconciliation was awaited — startup aborts with this error. This is a defensive invariant: reconciliation results must still map to a live registered client.
Source
Thrown at crates/live/src/node/mod.rs:908
)
})?;
match mass_status_result {
Ok(Some(mass_status)) => {
log_info!(
"Reconciling ExecutionMassStatus for {}",
client_id,
color = LogColor::Blue
);
let exec_engine_rc = self.kernel.exec_engine.clone();
let result = self
.exec_manager
.reconcile_execution_mass_status(mass_status, exec_engine_rc)
.await;
anyhow::ensure!(
self.kernel
.exec_engine
.borrow()
.get_client(&client_id)
.is_some(),
"Execution client {client_id} disappeared during startup reconciliation",
);
if result.events.is_empty() {
log_info!(
"Reconciliation for {} succeeded",
client_id,
color = LogColor::Blue
);
} else {
log::info!(
color = LogColor::Blue as u8;
"Reconciliation for {} processed {} events",View on GitHub (pinned to 18893faf8b)
Solutions
- Investigate adapter/venue logs to find why the client disconnected during reconciliation (session expiry, network drop) and fix the root cause.
- Retry startup once connections are stable; the client should remain registered throughout reconciliation.
- Update adapter credentials/session handling (auto-reconnect, keepalive) so clients are not deregistered mid-startup.
- Check adapter version for known disconnect/deregistration bugs and upgrade.
Defensive patterns
Strategy: validation
Validate before calling
// Before reconciliation, confirm client is registered and connection is healthy
let engine = node.kernel().exec_engine.borrow();
assert!(engine.get_client(&client_id).is_some(), "client {client_id} must be registered before reconciliation");
assert!(engine.get_client(&client_id).unwrap().is_connected(), "client {client_id} not connected"); Try / catch
match node.start().await {
Err(e) if e.to_string().contains("disappeared during startup reconciliation") => {
// reconnect/inspect adapter stability, then retry startup
}
other => other?,
} Prevention
- Enable adapter auto-reconnect and session keepalive
- Ensure credentials/session TTL outlasts startup reconciliation
- Run nodes on stable network links; avoid VPN drops mid-startup
- Check adapter changelogs for disconnect-during-report bugs
When it happens
Trigger: In perform_startup_reconciliation, after reconcile_execution_mass_status completes, self.kernel.exec_engine.borrow().get_client(&client_id) returns None (mod.rs:908-915), i.e. the client was removed between mass-status generation and post-reconcile validation.
Common situations: Broker WebSocket disconnects mid-reconciliation and the adapter deregisters the client; venue session expires during long mass-status generation; flaky network drops the client while its report is being processed.
Understand the failure class
Background: "Not found" and "does not exist" errors: why "Task not found", "No such folder", and "Can't find" fire when a lookup comes back empty — this error's family across 14 libraries.
Related errors
- Startup reconciliation timeout reached while requesting mass
- Finalized execution transaction {tx_hash} no longer has a re
- Finalized block {} changed from {} to {} before intent valid
- Finalized transaction {} emitted {} Swap logs; expected exac
- Binance Futures position has unresolved instrument {instrume
AI-assisted analysis of nautechsystems/nautilus_trader@18893faf8b (2026-09-08).
Data as JSON: /api/errors/622038cf7531aac9.
Report an issue: GitHub.