nautechsystems/nautilus_trader · error · anyhow::Error

Timeout waiting for account {account_id} to be registered af

Error message

Timeout waiting for account {account_id} to be registered after {timeout_secs}s

What it means

During Binance execution client startup, await_account_registered polls the cache every 10ms until the account state fetched from Binance is registered under the expected AccountId, bailing after timeout_secs. Hitting the timeout means the account pipeline never completed - most often because the account_id in config does not match the account the API key actually returns, or the underlying account info request failed earlier.

Source

Thrown at crates/adapters/binance/src/common/execution.rs:89

    if core.cache().account(&account_id).is_some() {
        log::info!("Account {account_id} registered");
        return Ok(());
    }

    let start = Instant::now();
    let timeout = Duration::from_secs_f64(timeout_secs);
    let interval = Duration::from_millis(10);

    loop {
        tokio::time::sleep(interval).await;

        if core.cache().account(&account_id).is_some() {
            log::info!("Account {account_id} registered");
            return Ok(());
        }

        if start.elapsed() >= timeout {
            anyhow::bail!(
                "Timeout waiting for account {account_id} to be registered after {timeout_secs}s"
            );
        }
    }
}

#[cfg(test)]
mod tests {
    use std::{cell::RefCell, rc::Rc};

    use nautilus_common::cache::Cache;
    use nautilus_live::ExecutionClientCore;
    use nautilus_model::{
        accounts::{AccountAny, CashAccount},
        enums::{AccountType, OmsType},
        events::AccountState,
        identifiers::{AccountId, TraderId},
        types::{AccountBalance, Money},

View on GitHub (pinned to a4b06ed870)

Solutions

  1. Scan earlier log lines - the root cause is usually a preceding account info request failure, not the timeout itself
  2. Verify the account_id in BinanceExecutionClientConfig matches the account the API key resolves to on that environment
  3. Confirm network egress to the correct Binance host (fapi/api vs testnet) and key validity
  4. Increase the startup timeout passed to await_account_registered on slow links

Example fix

# before
account_id = "BINANCE-TEST-001"   # live credentials -> never registers

# after
account_id = "BINANCE-001"        # matches the live account for the key
Defensive patterns

Strategy: retry

Validate before calling

// before starting the client, confirm the account is reachable for these creds
let info = binance_rest.get_account_info().await?; // surfaces the real error early
anyhow::ensure!(info.account_id == config.account_id, "config account_id {} != key's account {}", config.account_id, info.account_id);

Type guard

fn account_id_matches(configured: &AccountId, fetched: &AccountId) -> bool {
    configured == fetched
}

Try / catch

for attempt in 1..=3 {
    match await_account_registered(&core, account_id.clone(), timeout_secs).await {
        Ok(()) => break,
        Err(e) if attempt == 3 => return Err(e.context("account never registered - check account_id and earlier account-info errors")),
        Err(_) => { tokio::time::sleep(Duration::from_secs(2)).await; } // brief backoff, re-check prerequisites
    }
}

Prevention

When it happens

Trigger: Startup with a config account_id that differs from the account returned for the credentials (e.g. testnet account_id with live keys); an earlier account-info REST failure (connectivity, invalid key, wrong endpoint); timeout_secs configured too small for a slow network.

Common situations: Copying config between live/testnet without updating account_id; egress blocked to the wrong environment's API host; degraded/slow network on first start; earlier startup errors swallowed in the log.

Understand the failure class

Related errors


AI-assisted analysis of nautechsystems/nautilus_trader@a4b06ed870 (2026-08-16). Data as JSON: /api/errors/2dc826513470016b. Report an issue: GitHub.