nautechsystems/nautilus_trader · info

fixed tick scheme is valid

Error message

fixed tick scheme is valid

What it means

This panic lives in a static initializer for FIXED_TICK_SCHEME, a LazyLock that builds a FixedTickScheme with tick size 1.0. `FixedTickScheme::new` only fails for non-finite or non-positive tick sizes, which cannot happen here, so this expect documents an invariant that should never fire at runtime. If it does trigger, the constructor's validation logic itself has regressed.

Source

Thrown at crates/model/src/instruments/tick_scheme.rs:200

            (1_000.0, 3_000.0, 0.5),
            (3_000.0, 10_000.0, 1.0),
            (10_000.0, 30_000.0, 5.0),
            (30_000.0, 100_000.0, 10.0),
            (100_000.0, 300_000.0, 50.0),
            (300_000.0, 1_000_000.0, 100.0),
            (1_000_000.0, 3_000_000.0, 500.0),
            (3_000_000.0, 10_000_000.0, 1_000.0),
            (10_000_000.0, 30_000_000.0, 5_000.0),
            (30_000_000.0, f64::INFINITY, 10_000.0),
        ],
        4,
        10_000,
    )
    .expect("TOPIX100 tick scheme tiers are valid by construction")
});

static FIXED_TICK_SCHEME: LazyLock<FixedTickScheme> =
    LazyLock::new(|| FixedTickScheme::new(1.0).expect("fixed tick scheme is valid"));

static CRYPTO_0_01_TICK_SCHEME: LazyLock<FixedTickScheme> =
    LazyLock::new(|| FixedTickScheme::new(0.01).expect("crypto tick scheme is valid"));

static FIXED_PRECISION_TICK_SCHEMES: LazyLock<Vec<FixedTickScheme>> = LazyLock::new(|| {
    (0..=FIXED_PRECISION)
        .map(|precision| {
            let tick = 10_f64.powi(-i32::from(precision));
            FixedTickScheme::new(tick).expect("fixed precision tick scheme is valid")
        })
        .collect()
});

#[derive(Debug, Clone, Copy, PartialEq)]
pub struct FixedTickScheme {
    tick: f64,
}

View on GitHub (pinned to 18893faf8b)

Solutions

1. Inspect recent changes to FixedTickScheme::new — the validation is rejecting a valid tick by mistake.
2. Confirm the tick constant (1.0) is positive and finite.
3. Run the tick_scheme unit tests to pin down the regressed validation branch.
4. Keep the static as-is if reverting; it is correct by construction.

// Library-internal static; nothing for users to validate.
// If you maintain this code:
assert!(1.0_f64.is_finite() && 1.0 > 0.0);

When it happens

Trigger: Effectively untriggerable: would require the constant tick 1.0 to be rejected by FixedTickScheme::new, i.e. first access to the static after a code change broke the constructor or the constant.

Common situations: Developers would only encounter this after modifying FixedTickScheme::new validation or the tick constant in a patch, causing the first use of price rounding to panic on static init.

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

• crypto tick scheme is valid
• fixed precision tick scheme is valid
• Close command should not be drained
• Flush command should not be drained
• Order invariant violated: first event must be OrderInitializ

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