cube-js/cube · error

wait timeout is too large

Error message

wait timeout is too large

What it means

`poll` computes its deadline with `Instant::checked_add(timeout)`; if the supplied timeout is so large that adding it to the current instant overflows `tokio::time::Instant`, it returns `wait timeout is too large` instead of silently wrapping. This guards against pathological timeout values (e.g. `Duration::MAX`).

Source

Thrown at rust/cube-cli/src/wait.rs:131

                match last_label {
                    Some(label) => format!(" (last seen: {label})"),
                    None => String::new(),
                },
                if on_timeout.is_empty() {
                    String::new()
                } else {
                    format!(". {on_timeout}")
                },
                match streak {
                    Some((_, err)) => format!(". Last error: {err}"),
                    None => String::new(),
                }
            )
        };

    let deadline = tokio::time::Instant::now()
        .checked_add(timeout)
        .ok_or_else(|| anyhow::anyhow!("wait timeout is too large"))?;

    loop {
        let failures = streak.as_ref().map_or(0, |(count, _)| *count);

        let outcome = match tokio::time::timeout_at(deadline, attempt()).await {
            Ok(outcome) => outcome,
            // The request itself outlived the budget. Nothing arriving later can be
            // trusted as "within --timeout", so this ends the wait rather than
            // looping back to check the clock.
            Err(_) => return Err(timed_out(started.elapsed(), &last_label, &streak)),
        };

        match outcome {
            Ok(Progress::Done(value)) => return Ok(value),
            Ok(Progress::Waiting(label)) => {
                streak = None;
                if last_label.as_deref() != Some(label.as_str()) {
                    eprintln!("{what}: {label}");

View on GitHub (pinned to 7d981676b3)

Solutions

1. Pass a finite, realistic timeout (e.g. `Duration::from_secs(300)`).
2. If you want effectively-never-timeout, cap at a large but safe value like `Duration::from_secs(86400 * 365)`.
3. Audit unit conversions when building the Duration from config.
4. Handle this error variant explicitly at the call site if timeouts are user-configurable.

Example fix

// before
poll(what, attempt(), Duration::MAX).await?
// after
poll(what, attempt(), Duration::from_secs(3600)).await?

fn timeout_ok(d: std::time::Duration) -> bool {
    d < std::time::Duration::from_secs(86_400 * 365)
}

When it happens

Trigger: Calling `poll` with a timeout whose sum with the current monotonic clock reading exceeds the platform instant range — typically `Duration::MAX` or an absurdly large user-supplied value (test `rejects_a_timeout_that_cannot_fit_in_an_instant`).

Common situations: Using `Duration::MAX` as 'wait forever', multiplying a config value by the wrong unit (ms vs s), or forwarding an unset/zero-default numeric config into a Duration.

Understand the failure class

• Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

• timed out after {}s waiting for {what} (last seen: {label}).
• Athena job timeout reached ${this.config.pollTimeout}ms
• PoolTimeoutError
• CancelToken was already canceled
• BigQuery job timeout reached ${this.options.pollTimeout}ms

AI-assisted analysis of cube-js/cube@7d981676b3 (2026-09-02). Data as JSON: /api/errors/de917d0a014efcb4. Report an issue: GitHub.