risingwavelabs/risingwave · warning · HummockError

Barrier read is unavailable for now. Likely the cluster is r

Error message

Barrier read is unavailable for now. Likely the cluster is recovering

What it means

A barrier read was requested but no barrier is currently readable: the caller asked for the current/barrier epoch before the Hummock version has been updated by any barrier. Hummock returns this via `HummockError::read_current_epoch()` to signal a transient state — typically the cluster is starting up, restarting, or recovering and has not yet sealed a barrier. It is expected to clear once the meta node delivers the next barrier and the storage version advances.

Source

Thrown at src/storage/src/hummock/error.rs:63

    #[error("SharedBuffer error: {0}")]
    SharedBufferError(String),
    #[error("Wait epoch error: {0}")]
    WaitEpoch(String),
    #[error("Next epoch error: {0}")]
    NextEpoch(String),
    #[error("Change log retention miss: table {table_id}, epoch {epoch}")]
    ChangeLogRetentionMiss { table_id: TableId, epoch: u64 },
    #[error("Time-travel version expired: table {table_id}, epoch {epoch}")]
    TimeTravelVersionExpired { table_id: TableId, epoch: u64 },
    #[error(
        "Committed epoch mismatch: table {table_id}, committed_epoch {committed_epoch}, read_epoch {read_epoch}"
    )]
    CommittedEpochMismatch {
        table_id: TableId,
        committed_epoch: u64,
        read_epoch: u64,
    },
    #[error("Barrier read is unavailable for now. Likely the cluster is recovering")]
    ReadCurrentEpoch,
    #[error("CompactionExecutor error: {0}")]
    CompactionExecutor(String),
    #[error("FileCache error: {0}")]
    FileCache(String),
    #[error("SstObjectIdTracker error: {0}")]
    SstObjectIdTrackerError(String),
    #[error("CompactionGroup error: {0}")]
    CompactionGroupError(String),
    #[error("SstableUpload error: {0}")]
    SstableUploadError(String),
    #[error("Read backup error: {0}")]
    ReadBackupError(String),
    #[error("Foyer error: {0}")]
    FoyerError(#[from] foyer::Error),
    #[error("Other error: {0}")]
    Other(String),
}

View on GitHub (pinned to 6469eb736d)

Solutions

Retry the read after a short backoff — the error is transient by design.
Check barrier progress (barrier-complete latency / `await_epoch` metrics or logs) to confirm the cluster has sealed a barrier.
If it persists, investigate source connectivity or actor failures stalling barrier delivery; restart/recover the affected components.
During automated probing, add retry-with-backoff around barrier reads instead of failing immediately.

Example fix

// before: single attempt, fails during recovery
let epoch = hummock.read_current_epoch()?;
// after: retry until a barrier is readable
loop {
    match hummock.read_current_epoch() {
        Err(e) if matches!(e.inner(), HummockErrorInner::ReadCurrentEpoch) => {
            tokio::time::sleep(Duration::from_millis(500)).await;
        }
        other => break other.map(|v| v),
    }
}

Defensive patterns

Strategy: retry

Validate before calling

// Check cluster health before barrier reads:
// let ready = risingwave_healthcheck() && barrier_probe_ok();

Try / catch

match err.inner() {
    HummockErrorInner::ReadCurrentEpoch => {
        // transient: retry with exponential backoff until a barrier is sealed
    }
    _ => return Err(err),
}

Prevention

Always wrap barrier/current-epoch reads in retry-with-backoff; they are transient during recovery.
Delay application start until barrier-complete metrics confirm barriers are flowing.
Alert on barrier stall duration, not on individual ReadCurrentEpoch occurrences.
Avoid running reads immediately after cluster startup before the first barrier.

When it happens

Trigger: Calling APIs that read the current epoch/barrier (e.g. `HummockError::read_current_epoch()` from `src/storage/src/hummock/error.rs:145`) before the first barrier has been applied, or during a window where barrier delivery is stalled/recovering.

Common situations: Query issued immediately after cluster startup or crash recovery before barriers flow again; a stalled barrier due to slow sources or an unhealthy actor blocking the barrier loop; failover of the meta service leaving a gap in barrier progression.

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 risingwavelabs/risingwave@6469eb736d (2026-09-11). Data as JSON: /api/errors/a832f715cbebf805. Report an issue: GitHub.