What causes "relay duration is too large" in jdx/mise?

Reduce `request_timeout` and `max_duration` to realistic durations (minutes/hours, not centuries).

relay duration is too large

Error message

relay duration is too large

What it means

During `configure`, the relay computes `Instant::now() + timeout` and `Instant::now() + max_duration`; if either addition overflows the platform's `Instant` representation, the configured durations are unrepresentably large and configuration fails with this error. It protects the relay from scheduling values that would panic on arithmetic later.

Source

Thrown at src/github_relay.rs:109

    let settings = &settings.github_relay;
    let format = format.unwrap_or(&settings.log_format);
    if !matches!(format, "text" | "jsonl") {
        bail!("relay log format must be text or jsonl");
    }
    let timeout = duration::parse_duration(&settings.request_timeout)?;
    if timeout.is_zero() {
        bail!("relay request timeout must be greater than zero");
    }
    if !(1..=32).contains(&settings.concurrency) {
        bail!("relay concurrency must be between 1 and 32");
    }
    let max_duration = duration::parse_duration(max_duration.unwrap_or(&settings.max_duration))?;
    if std::time::Instant::now().checked_add(timeout).is_none()
        || std::time::Instant::now()
            .checked_add(max_duration)
            .is_none()
    {
        bail!("relay duration is too large");
    }
    #[cfg(not(unix))]
    let _ = max_duration;
    #[cfg(unix)]
    let scope = {
        let mut scope = scope;
        scope.options = Options {
            log_requests: !no_log_requests && (log_requests || settings.log_requests),
            jsonl: format == "jsonl",
            max_duration,
            request_timeout: timeout,
            concurrency: settings.concurrency as usize,
        };
        scope
    };
    Ok(Some(scope))
}

View on GitHub (pinned to afd2eddd3a)

Solutions

Reduce `request_timeout` and `max_duration` to realistic durations (minutes/hours, not centuries).
Omit or reset the override to the default if you wanted 'effectively unlimited' timeout.
Verify the duration string parses to the intended unit with the library's duration parser first.

Example fix

// before
MISE_GITHUB_RELAY_MAX_DURATION=99999999999999999999s
// after
MISE_GITHUB_RELAY_MAX_DURATION=1h

Defensive patterns

Strategy: validation

Validate before calling

use std::time::{Duration, Instant};
fn duration_representable(d: Duration) -> bool {
    Instant::now().checked_add(d).is_some()
}

Type guard

fn sane_duration(d: Duration) -> Option<Duration> {
    (d <= Duration::from_secs(30 * 24 * 3600)).then_some(d)
}

Try / catch

match relay::configure(&settings, max_override) {
    Err(e) if e.to_string().contains("too large") => eprintln!("reduce timeout/max_duration: {e}"),
    Err(e) => return Err(e),
    Ok(v) => v,
}

Prevention

Cap configured durations at a sane maximum (e.g. 24h) in your own config layer.
Never use gigantic sentinel values for 'no timeout'; omit the setting instead.
Validate duration strings parse and are within bounds before passing them in.

When it happens

Trigger: Setting `request_timeout` or `max_duration` (or the explicit `max_duration` override argument) to an extremely large duration string, e.g. `9999999999999999999s` or a multi-century duration, such that now+duration overflows `Instant`.

Common situations: Users trying to express 'no timeout' with a huge number instead of omitting the setting; unit mistakes like writing milliseconds as nanoseconds; or a misparsed config value like `999999y`.

Understand the failure class

Background: "Invalid value" and "allowed values are" config errors: what your library rejected and how to fix it — this error's family across 41 libraries.

Related errors

AI-assisted analysis of jdx/mise@afd2eddd3a (2026-09-09). Data as JSON: /api/errors/751c627c1b5f8466. Report an issue: GitHub.