nautechsystems/nautilus_trader · error

non-positive candle high `{}`

Error message

non-positive candle high `{}`

What it means

parse_candle_bar requires a candle's high price to be strictly positive before constructing a Price. A non-positive high indicates malformed, placeholder, or corrupt data from the Lighter candles endpoint. The error message embeds the offending value.

Source

Thrown at crates/adapters/lighter/src/http/parse.rs:192

}

/// Parses a Lighter candle into a Nautilus [`Bar`].
///
/// # Errors
///
/// Returns an error if any price, volume, or timestamp field cannot be converted.
pub fn parse_candle_bar(
    candle: &LighterCandle,
    bar_type: BarType,
    instrument: &InstrumentAny,
    ts_init: UnixNanos,
) -> anyhow::Result<Bar> {
    anyhow::ensure!(
        candle.open > Decimal::ZERO,
        "non-positive candle open `{}`",
        candle.open
    );
    anyhow::ensure!(
        candle.high > Decimal::ZERO,
        "non-positive candle high `{}`",
        candle.high
    );
    anyhow::ensure!(
        candle.low > Decimal::ZERO,
        "non-positive candle low `{}`",
        candle.low
    );
    anyhow::ensure!(
        candle.close > Decimal::ZERO,
        "non-positive candle close `{}`",
        candle.close
    );

    let timestamp_ms =
        u64::try_from(candle.timestamp).context("negative Lighter candle timestamp")?;
    let ts_event = parse_millis_to_nanos(timestamp_ms)?;

View on GitHub (pinned to 18893faf8b)

Solutions

  1. Filter out candles with high <= 0 before parsing
  2. Inspect the raw Lighter API response for the offending candle
  3. Verify the market is active/trading and the requested time range contains real trades
  4. Correct fixture data used in tests to hold positive OHLC

Example fix

// before
for candle in candles { bars.push(parse_candle_bar(candle, ...)?); }
// after
for candle in candles.into_iter().filter(|c| c.high > Decimal::ZERO) { bars.push(parse_candle_bar(candle, ...)?); }
Defensive patterns

Strategy: validation

Validate before calling

if candle.high <= Decimal::ZERO {
    return Err(anyhow::anyhow!("skip candle: non-positive high {}", candle.high));
}

Type guard

fn has_positive_ohlc(c: &LighterCandle) -> bool {
    c.open > Decimal::ZERO && c.high > Decimal::ZERO && c.low > Decimal::ZERO && c.close > Decimal::ZERO
}

Try / catch

let bar = match parse_candle_bar(&candle, bar_type, instrument, ts_init) {
    Ok(b) => b,
    Err(e) if e.to_string().contains("non-positive candle high") => continue,
    Err(e) => return Err(e),
};

Prevention

When it happens

Trigger: parse_candle_bar receiving a LighterCandle with high <= 0 while parsing a candles HTTP response via parse_bars.

Common situations: Illiquid or empty markets returning zeroed candles; mock/fixture data with zeros; upstream API data corruption during incidents.

Understand the failure class

Background: "Must be a positive integer", "Invalid value", "Unsupported": the invalid-argument-value error family, when a library rejects the value you pass — this error's family across 35 libraries.

Related errors


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