nautechsystems/nautilus_trader · error

{price_field} {price} must be greater than zero and less tha

Error message

{price_field} {price} must be greater than zero and less than one

What it means

The second half of validate_pending_trade_values asserts the price Decimal is a valid probability: strictly greater than zero and strictly less than one. Any value outside the open interval (0, 1) triggers this anyhow error with the caller-provided field label.

Source

Thrown at crates/adapters/polymarket/src/execution/reconciliation.rs:422

    size_precision: u8,
    quantity_field: &str,
    price_field: &str,
) -> anyhow::Result<Price> {
    validate_quantity_evidence(quantity, size_precision, quantity_field, false)?;
    validate_historical_price_evidence(price, price_field)
}

fn validate_pending_trade_values(
    quantity: Decimal,
    price: Decimal,
    quantity_field: &str,
    price_field: &str,
) -> anyhow::Result<()> {
    anyhow::ensure!(
        quantity > Decimal::ZERO,
        "{quantity_field} {quantity} must be positive"
    );
    anyhow::ensure!(
        price > Decimal::ZERO && price < Decimal::ONE,
        "{price_field} {price} must be greater than zero and less than one",
    );
    Ok(())
}

fn require_trade_timestamp(
    ts_event: Option<UnixNanos>,
    trade: &PolymarketTradeReport,
) -> anyhow::Result<UnixNanos> {
    ts_event.with_context(|| {
        format!(
            "selected trade {} has invalid match_time {}",
            trade.id, trade.match_time,
        )
    })
}

View on GitHub (pinned to 18893faf8b)

Solutions

  1. Normalize provider prices: divide percentages by 100 so the value lies in (0, 1) before validation.
  2. Exclude resolved or fully-determined markets where the price is 0 or 1 from pending-trade reconciliation.
  3. Verify the correct column/field is passed as price rather than quantity.

Example fix

// before
let price = Decimal::from(55); // 55% as integer
validate_pending_trade_values(qty, price, "size", "price")?;
// after
let price = Decimal::from(55) / Decimal::from(100); // 0.55
validate_pending_trade_values(qty, price, "size", "price")?;
Defensive patterns

Strategy: validation

Validate before calling

fn is_probability(v: rust_decimal::Decimal) -> bool {
    v > rust_decimal::Decimal::ZERO && v < rust_decimal::Decimal::ONE
}
let price = if raw_price > Decimal::ONE { raw_price / Decimal::from(100) } else { raw_price }; // de-percentize

Type guard

fn is_valid_pending_price(p: &rust_decimal::Decimal) -> bool {
    *p > rust_decimal::Decimal::ZERO && *p < rust_decimal::Decimal::ONE
}

Try / catch

match validate_pending_trade_values(qty, price, "size", "price") {
    Err(e) if e.to_string().contains("greater than zero and less than one") => {
        let normalized = price / Decimal::from(100); // handle percent-encoded feeds
        validate_pending_trade_values(qty, normalized, "size", "price")?
    }
    other => other?,
}

Prevention

When it happens

Trigger: classify_target_trade passes a pending trade price <= 0 or >= 1 into validate_pending_trade_values — e.g. a provider price of exactly 1.0, 0, a percentage value like 55 (instead of 0.55), or a mis-scaled raw integer.

Common situations: Provider feeds returning prices as whole percentages; price 1.0 for resolved/100%-likely outcomes; swapping price and size columns when parsing provider exports.

Understand the failure class

Background: "value must be between 0 and 1" / "out of range" / "must not be negative" errors: fixing range-validation failures across open-source libraries — this error's family across 42 libraries.

Related errors


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