What causes "The provided time parameters lead to an overflow" in FuelLabs/fuel-core?

Use small, realistic intervals (seconds-scale) for Trigger::Interval block_time and Trigger::Open period.

The provided time parameters lead to an overflow

Error message

The provided time parameters lead to an overflow

What it means

increase_time(Tai64, Duration) adds duration.as_secs() to the Tai64 seconds counter (a u64) with checked_add and errors on overflow. It is the single helper behind next_time for both manual and trigger requests, so any block_time/period/elapsed-time combination that would push the next block timestamp past u64::MAX seconds fails here.

Source

Thrown at crates/services/consensus_module/poa/src/service.rs:861

        config,
        txpool,
        block_producer,
        block_importer,
        p2p_port,
        block_signer,
        predefined_blocks,
        clock,
        block_production_ready_signal,
        reconciliation_port,
    ))
}

fn increase_time(time: Tai64, duration: Duration) -> anyhow::Result<Tai64> {
    let timestamp = time.0;
    let timestamp = timestamp
        .checked_add(duration.as_secs())
        .ok_or(anyhow::anyhow!(
            "The provided time parameters lead to an overflow"
        ))?;
    Ok(Tai64(timestamp))
}

View on GitHub (pinned to b9d4d170da)

Solutions

Use small, realistic intervals (seconds-scale) for Trigger::Interval block_time and Trigger::Open period.
Do not pass manual start_times near Tai64::MAX; prefer None and let next_time derive the value.
If the chain head timestamp is already extreme (from earlier manual jumps), reset the test chain or continue with explicit lower-but-monotonic start_times.

Example fix

// before
let config = Config {
    trigger: Trigger::Interval { block_time: Duration::from_secs(u64::MAX) },
    ..Default::default()
};

// after
let config = Config {
    trigger: Trigger::Interval { block_time: Duration::from_secs(10) },
    ..Default::default()
};

Defensive patterns

Strategy: validation

Validate before calling

// Mirror increase_time's checked arithmetic before triggering production
fn next_timestamp_fits(last_timestamp: Tai64, step: std::time::Duration) -> bool {
    last_timestamp.0.checked_add(step.as_secs()).is_some()
}

if !next_timestamp_fits(head.time(), trigger_step) {
    anyhow::bail!("head timestamp + trigger step would overflow Tai64");
}

Type guard

fn increase_time_checked(time: Tai64, duration: std::time::Duration) -> Option<Tai64> {
    time.0.checked_add(duration.as_secs()).map(Tai64)
}

Try / catch

match result {
    Err(err) if err.to_string().contains("lead to an overflow") => {
        // permanent config/state issue: fix trigger interval or reset the chain's timestamps
    }
    other => other,
}

Prevention

Keep trigger intervals at realistic second-scale values.
Avoid manual start_times near Tai64::MAX; prefer None and let the service derive timestamps.
Unit-test config parsing so millisecond values cannot silently become Duration::from_secs.

When it happens

Trigger: next_time(RequestType::Manual) computing last_timestamp + block_time/period/elapsed where the sum overflows u64; manual start_times near Tai64::MAX followed by further next_time advances; huge Interval block_time or Open period in config added to the head timestamp.

Common situations: Config unit mistakes (a value intended as milliseconds parsed as seconds via Duration::from_secs); test chains whose timestamps were advanced close to Tai64::MAX by manual production; unbounded integers from config files fed straight into Duration.

Related errors

AI-assisted analysis of FuelLabs/fuel-core@b9d4d170da (2026-08-16). Data as JSON: /api/errors/a667c9ed17cc6b31. Report an issue: GitHub.