nautechsystems/nautilus_trader · error

Cannot request aggregated bars: one of the aggregators in `b

Error message

Cannot request aggregated bars: one of the aggregators in `bar_types` is already running

What it means

Before starting bar aggregators for a new request, the engine checks can_start_request_bar_aggregators; if any aggregator for one of the requested bar_types is already running for another request, it refuses to avoid duplicate aggregation. This guards against conflicting concurrent bar aggregation for the same bar type.

Source

Thrown at crates/data/src/engine/mod.rs:1521

        target.activation_ns = UnixNanos::default();
        target.expiration_ns = UnixNanos::default();

        if let Err(e) = self
            .cache
            .borrow_mut()
            .add_instrument(InstrumentAny::FuturesContract(target))
        {
            log_error_on_cache_insert(&e);
        }
    }

    fn prepare_request_bar_aggregators_from_state(
        &mut self,
        request_id: UUID4,
        state: &RequestBarAggregation,
    ) -> anyhow::Result<()> {
        if !self.can_start_request_bar_aggregators(request_id, state) {
            anyhow::bail!(
                "Cannot request aggregated bars: one of the aggregators in `bar_types` is already running"
            );
        }

        self.request_bar_aggregations
            .insert(request_id, state.clone());

        if let Err(e) = self.init_request_bar_aggregators(request_id, state) {
            self.cleanup_request_bar_aggregators(&request_id);
            return Err(e);
        }

        Ok(())
    }

    fn dispatch_next_continuous_future_segment(&mut self, request_id: UUID4) -> anyhow::Result<()> {
        let Some(state) = self.continuous_future_requests.get(&request_id).cloned() else {
            anyhow::bail!("No active continuous future request for {request_id}");

View on GitHub (pinned to 18893faf8b)

Solutions

  1. Cancel or let the earlier bar request complete before issuing an identical aggregation request
  2. Reuse the existing bar subscription/request instead of requesting the same bar_types aggregation again
  3. Use a distinct bar_type (different aggregation source or interval) if both requests are genuinely needed
  4. If aggregators are stale, reset/restart the engine or deregister the prior request's aggregation state

Example fix

// before
engine.request_bars(bar_req_1min);
engine.request_bars(bar_req_1min); // duplicate aggregation
// after
if !engine.has_bars(bar_req_1min.bar_type()) {
    engine.request_bars(bar_req_1min);
} else {
    // reuse existing subscription
}
Defensive patterns

Strategy: validation

Validate before calling

// skip duplicate aggregation requests
if engine.has_bars(&bar_type) {
    log::info!("aggregation already active for {bar_type}");
    return Ok(());
}
engine.request_bars(req);

Try / catch

match engine.request_bars(req) {
    Err(e) if e.to_string().contains("already running") => {
        log::warn!("reusing existing aggregators for requested bar_types");
    }
    other => other?,
}

Prevention

When it happens

Trigger: Calling DataEngine.request_bars (or a second bars request with the same bar_types aggregation) while a previous request's aggregators for those bar_types are still active — e.g. requesting 1-MINUTE bars from 1-SECOND trades while an identical aggregation is already registered.

Common situations: Re-issuing a bars request without canceling/deregistering the previous one; two strategies independently requesting the same aggregated bar type from the same source; restarting a backtest segment without cleaning up prior aggregation state.

Related errors


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