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
- Normalize provider prices: divide percentages by 100 so the value lies in (0, 1) before validation.
- Exclude resolved or fully-determined markets where the price is 0 or 1 from pending-trade reconciliation.
- 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
- Detect and convert whole-number percentage feeds at ingestion
- Exclude resolved markets (price 0 or 1) from pending-trade reconciliation
- Assert price < 1 in your own order-submission layer so bad data never reaches reconciliation
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
- unmapped_in_scope_message("open order", instrument_id, Some(
- unmapped_in_scope_message("position", instrument_id, None, c
- invalid market-buy price {price}: must satisfy 0 < price < 1
- expected Polymarket BinaryOption instrument, found {instrume
- provider venue order {} is not owned by the account
AI-assisted analysis of nautechsystems/nautilus_trader@18893faf8b (2026-09-08).
Data as JSON: /api/errors/503d0857adc7d8b0.
Report an issue: GitHub.