nautechsystems/nautilus_trader · error · anyhow::Error

Invalid config type for BinanceDataClientFactory. Expected…

Error message

Invalid config type for BinanceDataClientFactory. Expected BinanceDataClientConfig, was {config:?}

What it means

BinanceDataClientFactory::create expects the passed ComponentConfig to be a BinanceDataClientConfig. It performs a downcast_ref and throws this error if the config object is a different type or missing, i.e. the factory was handed a config that does not match the client it builds.

Solutions

Ensure the data-client entry in the node config uses BinanceDataClientConfig for the factory-named client.
Check that the config key in the clients map matches the name given to BinanceDataClientFactory at registration.
If mixing adapters, verify each factory receives its own adapter's config type.
After an upgrade, update any renamed config types to BinanceDataClientConfig.

Example fix

// before
data_clients: { "BINANCE": BybitDataClientConfig { .. } }  // wrong adapter config
// after
data_clients: { "BINANCE": BinanceDataClientConfig { .. } }

Defensive patterns

Strategy: type-guard

Validate before calling

// before calling the factory, verify the config type
fn is_binance_data_config(cfg: &dyn std::any::Any) -> bool {
    cfg.downcast_ref::<BinanceDataClientConfig>().is_some()
}

Type guard

fn as_binance_data_config(cfg: &dyn std::any::Any) -> Option<&BinanceDataClientConfig> {
    cfg.downcast_ref::<BinanceDataClientConfig>()
}

Try / catch

match factory.create(...) {
    Ok(client) => { /* use client */ }
    Err(e) if e.to_string().contains("Invalid config type for BinanceDataClientFactory") => {
        // inspect the clients map: the config for this client name is not BinanceDataClientConfig
    }
    Err(e) => { /* other failure */ }
}

Prevention

Keep one config type per adapter factory; never share a clients-map entry across adapters.
Match client names in the config to the names factories were registered under.
After adapter upgrades, grep configs for renamed config types.
Validate the whole node config at startup so mismatches surface before the node runs.

When it happens

Trigger: Registering BinanceDataClientFactory with the Node/Kernel but supplying a BinanceLiveExecClientConfig, BinanceClientConfig, or any other config struct (or a config of the wrong adapter, e.g. Bybit) in the clients map for the data client.

Common situations: Mixing adapters in a node config so the data client entry points at another adapter's config; renaming/migrating config types across versions and the factory now expects BinanceDataClientConfig; typos in the clients config section.

Related errors

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

Appendix: source

Thrown at crates/adapters/binance/src/factories.rs:80

impl Default for BinanceDataClientFactory {
    fn default() -> Self {
        Self::new()
    }
}

impl DataClientFactory for BinanceDataClientFactory {
    fn create(
        &self,
        name: &str,
        config: &dyn ClientConfig,
        _cache: CacheView,
        _clock: Rc<RefCell<dyn Clock>>,
    ) -> anyhow::Result<Box<dyn DataClient>> {
        let binance_config = config
            .as_any()
            .downcast_ref::<BinanceDataClientConfig>()
            .ok_or_else(|| {
                anyhow::anyhow!(
                    "Invalid config type for BinanceDataClientFactory. Expected BinanceDataClientConfig, was {config:?}",
                )
            })?
            .clone();

        let client_id = ClientId::from(name);

        binance_config.validate()?;

        let product_type = binance_config.product_type;

        match product_type {
            BinanceProductType::Spot => {
                let client = BinanceSpotDataClient::new(client_id, binance_config)?;
                Ok(Box::new(client))
            }
            BinanceProductType::UsdM | BinanceProductType::CoinM => {
                let client =

View on GitHub (pinned to 18893faf8b)