databendlabs/databend · error

timeout; no error received

Error message

timeout; no error received

What it means

register_node retries a registration operation in a loop, keeping the last concrete error in last_err. If the retry budget expires without ever capturing an error (all attempts timed out at a layer that swallowed the error, e.g. awaiting a response future that hit its own timeout returning None), the function returns this generic timeout error. It means registration did not complete within the allowed window and no more specific cause is available.

Solutions

  1. Verify network reachability and the leader's raft gRPC endpoint from the registering node (nc/curl the raft addr).
  2. Check the leader's logs for election activity or overload; wait for a stable leader before registering.
  3. Increase the registration retry/timeout window if the cluster is legitimately slow to converge.
  4. If timeouts are silent (last_err never set), add instrumentation/timeouts that record the concrete per-attempt error so the message is actionable.

Example fix

// before
Err(anyhow::anyhow!("timeout; no error received"))
// after
Err(anyhow::anyhow!(
    "timeout registering node after {} attempts within {:?}; last_err={:?}",
    attempts, elapsed, last_err
))
Defensive patterns

Strategy: retry

Validate before calling

// Shell: confirm the raft endpoint answers before registering
timeout 5 bash -c "</dev/tcp/<leader_host>/<raft_port>" || echo 'leader unreachable'

Try / catch

match register_node(...).await {
    Ok(()) => (),
    Err(e) if e.to_string().contains("timeout") => {
        // back off and retry once the leader is stable
        tokio::time::sleep(Duration::from_secs(10)).await;
        return register_node(...).await;
    }
    Err(e) => return Err(e),
}

Prevention

When it happens

Trigger: All registration attempts exhaust the retry loop with the inner operation timing out (or returning Ok(None)-style outcomes that don't set last_err), reaching the fallthrough Err at the end of the function.

Common situations: Registering a node into a cluster whose raft leader is unreachable/slow (network partition, overloaded leader); misconfigured raft listen addresses; long elections leaving the client to time out repeatedly.

Understand the failure class

Background: Request timed out: what client-side request timeouts mean across libraries (Request timed out, TIMED_OUT, APITimeoutError) — this error's family across 39 libraries.

Related errors


AI-assisted analysis of databendlabs/databend@288d84d76e (2026-09-11). Data as JSON: /api/errors/f496b5677eefe1e6. Report an issue: GitHub.

Appendix: source

Thrown at src/meta/binaries/meta/entry.rs:386

                    "Error while registering node: {}, sleep {:?} and retry",
                    e, sleep_time
                );
                println!("    Error: {}", e);
                println!("    Sleep {:?} and retry", sleep_time);
                println!();

                last_err = Some(e);
                sleep(sleep_time).await;
                sleep_time = std::cmp::min(sleep_time * 2, Duration::from_secs(5));
            }
        }
    }

    if let Some(e) = last_err {
        return Err(e);
    }

    Err(anyhow::anyhow!("timeout; no error received"))
}

fn run_cmd(conf: &MetaConfig) -> bool {
    if conf.cmd.is_empty() {
        return false;
    }

    match conf.cmd.as_str() {
        "ver" => {
            println!("version: {}", DATABEND_SEMVER.deref());
            println!(
                "min-compatible-client-version: {}",
                *MIN_QUERY_VER_FOR_METASRV
            );
            println!("data-version: {:?}", DATA_VERSION);
        }
        "show-config" => {
            println!(

View on GitHub (pinned to 288d84d76e)