nautechsystems/nautilus_trader · error

No aggregator for continuous future request {request_id}

Error message

No aggregator for continuous future request {request_id}

What it means

When processing a continuous futures request segment, the engine looks up the bar aggregator registered under the request's primary bar type (`bar_aggregator_key`) to apply the price adjustment for that segment. If no aggregator exists under that key, this error is returned. It is an internal consistency error: a continuous future request is being handled without its corresponding aggregator having been created/registered.

Source

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

        self.apply_continuous_future_adjustment(request_id, &state.request, segment.index)?;
        let child = self.build_continuous_future_child_request(request_id, &state, segment);
        if let Some(active) = self.continuous_future_requests.get_mut(&request_id) {
            active.cursor_ns = UnixNanos::from(segment.end_ns.saturating_add(1));
        }

        self.dispatch_request_to_client(child).map(|_| ())
    }

    fn apply_continuous_future_adjustment(
        &self,
        request_id: UUID4,
        request: &ContinuousFutureRequest,
        segment_index: usize,
    ) -> anyhow::Result<()> {
        let adjustment = request.adjustment_for_segment(segment_index);
        let key = bar_aggregator_key(request.primary_bar_type, Some(request_id));
        let aggregator = self.bar_aggregators.get(&key).ok_or_else(|| {
            anyhow::anyhow!("No aggregator for continuous future request {request_id}")
        })?;
        aggregator
            .borrow_mut()
            .set_adjustment(adjustment, request.adjustment_mode);

        Ok(())
    }

    fn build_continuous_future_child_request(
        &self,
        request_id: UUID4,
        state: &ContinuousFutureRequestState,
        segment: ContinuousFutureSegment,
    ) -> RequestCommand {
        let source = state.request.source_for_segment(segment.instrument_id);
        let start = Some(UnixNanos::from(segment.start_ns).to_datetime_utc());
        let end = Some(UnixNanos::from(segment.end_ns).to_datetime_utc());
        let child_params = Some(

View on GitHub (pinned to 18893faf8b)

Solutions

1. Ensure the continuous future request goes through the standard request path that first creates and registers the bar aggregator for the primary bar type before segment adjustment runs.
2. Verify the bar type in the request (step size, aggregation source, price/instrument type) exactly matches the one used when the aggregator was registered — fix the request spec.
3. Check logs for a prior failure or unsubscribe that removed the aggregator for this request_id and reissue the full request.
4. If reproducible with a consistent request, report as an internal invariant violation with the request parameters, since callers normally cannot hit this path.

Example fix

// before: requesting continuous futures with a bar_type that never got an aggregator
let request = ContinuousFutureRequest::new(bar_type_with_step_1min, ...);

// after: use the same bar type spec the aggregator was registered with
let request = ContinuousFutureRequest::new(registered_primary_bar_type, ...);

# Caller-side: confirm the request's bar type matches an existing aggregator registration
key = (request.primary_bar_type, request_id)
if key not in engine.bar_aggregators:
    logger.warning(f"no aggregator for {request_id} with bar type {request.primary_bar_type}; reissuing full request")
    engine.recreate_continuous_future_request(request)  # full request path re-registers the aggregator

match engine.set_continuous_future_adjustment(request_id, segment_index) {
    Ok(()) => {}
    Err(e) if e.to_string().starts_with("No aggregator for continuous future request") => {
        // aggregator was never registered or was torn down; restart the request from scratch
        warn!("aggregator missing for {request_id}; reissuing full continuous future request");
        engine.handle_continuous_future_request(request)?;
    }
    Err(e) => return Err(e),
}

When it happens

Trigger: Calling `_handle_continuous_future`-style processing (setting adjustment for segment `segment_index` of `request_id`) when the aggregator map has no entry for `(primary_bar_type, request_id)` — e.g. the aggregator was never created because the initial subscription/request setup failed or was skipped, or it was removed/cleaned up before segment processing, or the bar type in the request doesn't match the one used at aggregator creation (aggregation mismatch such as step vs tick aggregation).

Common situations: Requesting continuous futures data with a bar type/aggregation spec that differs from the one the aggregator was created with; teardown of the subscription between the initial request and the adjustment update; internal state corruption after a failed prior request left partial registration.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

• Continuous future requests require `RequestBars`
• No active continuous future request for {request_id}
• Continuous future bar subscription requires `continuous_futu
• Logging is running without a published sender
• No client registered with ID {client_id}

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