nautechsystems/nautilus_trader · error

`rtype` is not a supported bar aggregation, was {msg.hd.rtyp

Error message

`rtype` is not a supported bar aggregation, was {msg.hd.rtype}

What it means

`decode_bar_type` maps the Databento record's `rtype` header to a Nautilus `BarType`. If the `rtype` does not correspond to a supported OHLCV bar aggregation (e.g. a seconds/minutes/hours/eod mapping the decoder knows), it bails with this message because it cannot represent the record as a bar.

Source

Thrown at crates/adapters/databento/src/decode/market_data.rs:669

            BarType::new(instrument_id, BAR_SPEC_1S, AggregationSource::External)
        }
        33 => {
            // ohlcv-1m
            BarType::new(instrument_id, BAR_SPEC_1M, AggregationSource::External)
        }
        34 => {
            // ohlcv-1h
            BarType::new(instrument_id, BAR_SPEC_1H, AggregationSource::External)
        }
        35 => {
            // ohlcv-1d
            BarType::new(instrument_id, BAR_SPEC_1D, AggregationSource::External)
        }
        36 => {
            // ohlcv-eod
            BarType::new(instrument_id, BAR_SPEC_1D, AggregationSource::External)
        }
        _ => anyhow::bail!(
            "`rtype` is not a supported bar aggregation, was {}",
            msg.hd.rtype
        ),
    };

    Ok(bar_type)
}

/// # Errors
///
/// Returns an error if `rtype` is not a supported bar aggregation.
pub fn decode_ts_event_adjustment(msg: &dbn::OhlcvMsg) -> anyhow::Result<DurationNanos> {
    let adjustment = match msg.hd.rtype {
        32 => {
            // ohlcv-1s
            BAR_CLOSE_ADJUSTMENT_1S
        }
        33 => {

View on GitHub (pinned to 18893faf8b)

Solutions

  1. Request only supported bar aggregations (1-second, 1-minute, 1-hour, 1-day, eod)
  2. Upgrade the adapter crate to get mappings for newer rtypes
  3. Aggregate higher-level bars locally from a supported base interval instead
  4. Log the rtype value and check the dbn crate's rtype documentation

Example fix

// before
request_bars(bar_spec=MIN_5) // yields unsupported rtype
// after
request_bars(bar_spec=MIN_1) // supported, aggregate 5m locally
Defensive patterns

Strategy: validation

Validate before calling

const SUPPORTED_BAR_RTYPES: &[u16] = &[32, 33, 34, 35, 36]; // match adapter mapping
fn is_supported_bar_rtype(rtype: u16) -> bool { SUPPORTED_BAR_RTYPES.contains(&rtype) }

Try / catch

match decode_record(record) {
    Ok(data) => data,
    Err(e) if e.to_string().contains("not a supported bar aggregation") => { /* skip record or resubscribe with supported interval */ }
    Err(e) => return Err(e),
}

Prevention

When it happens

Trigger: Subscribing or requesting bars and receiving a record whose `hd.rtype` is outside the supported bar set (supported: known OHLCV rtypes like 32/33/34/35/36 for 1s/1m/1h/1d/eod variants); decoding a non-bar record through the bar path.

Common situations: Requesting an unconventional bar interval from Databento (e.g. 5-minute bars via a custom rtype) that the decoder has no mapping for; Databento adding new rtypes the adapter version predates.

Related errors

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