What causes "recv_window_ms must be in the inclusive range 1..=60000, was {recv_window_ms}" in nautechsystems/nautilus_trader?

Choose a value in 1..=60000, e.g. the default or 5000-10000 for typical use.

recv_window_ms must be in the inclusive range 1..=60000, was

Error message

recv_window_ms must be in the inclusive range 1..=60000, was {recv_window_ms}

What it means

Binance signs every private REST request with a recvWindow timestamp parameter, and the exchange caps it at 60,000 ms. validate_recv_window enforces the inclusive range 1..=60000 on both data and execution client configs so requests are never rejected server-side with a 'Timestamp outside of the recvWindow' error.

Source

Thrown at crates/adapters/binance/src/config.rs:453

        self.instrument_provider.validate(self.product_type)?;

        if self.us {
            anyhow::ensure!(
                self.product_type == BinanceProductType::Spot,
                "Binance US supports Spot clients only"
            );
            anyhow::ensure!(
                self.environment == BinanceEnvironment::Live,
                "Binance US supports the Live environment only"
            );
        }

        Ok(())
    }
}

fn validate_recv_window(recv_window_ms: u64) -> anyhow::Result<()> {
    anyhow::ensure!(
        (1..=60_000).contains(&recv_window_ms),
        "recv_window_ms must be in the inclusive range 1..=60000, was {recv_window_ms}"
    );
    Ok(())
}

impl ClientConfig for BinanceExecClientConfig {
    fn as_any(&self) -> &dyn Any {
        self
    }
}

#[cfg(test)]
mod tests {
    use rstest::rstest;

    use super::*;

View on GitHub (pinned to a4b06ed870)

Solutions

Choose a value in 1..=60000, e.g. the default or 5000-10000 for typical use.
If you hit recvWindow server errors, fix the host clock (NTP sync) instead of raising the window past 60000.
On high-latency links, use a moderate window (10000-30000) rather than the maximum.

Example fix

# before
BinanceExecClientConfig(recv_window_ms=120_000)  # above exchange cap

# after
BinanceExecClientConfig(recv_window_ms=10_000)

Defensive patterns

Strategy: validation

Validate before calling

assert 1 <= int(config.recv_window_ms) <= 60_000, \
    'recv_window_ms must be in 1..=60000'
config.validate()

Prevention

Keep recv_window_ms at the default or in 5000-30000 range.
Sync host clocks with NTP instead of widening the window past 60000.
Reject configs loaded from files whose recv_window_ms is absent or zero.

When it happens

Trigger: Setting recv_window_ms=0 (meaning 'omit'), a negative number, or anything above 60000 (e.g. 120000) in BinanceDataClientConfig or BinanceExecClientConfig; validate() runs in the factory at client creation.

Common situations: Trying to work around clock drift between the local machine and Binance servers by inflating recv_window_ms beyond the exchange cap; passing 0 expecting it to disable the parameter; migrating a value from another library that allows larger windows.

Related errors

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