risingwavelabs/risingwave · error · MetaError

Hummock error: {0}

Error message

Hummock error: {0}

What it means

MetaError::HummockError wraps the Hummock (RisingWave's cloud-native storage engine) error type into the meta error enum, displayed as 'Hummock error: {inner}'. Any failure in the state-store layer touched from the meta service (SST operations, version management, remote storage) surfaces through this wrapper.

Source

Thrown at src/meta/src/error.rs:52

    thiserror::Error,
    thiserror_ext::ReportDebug,
    thiserror_ext::Arc,
    thiserror_ext::Construct,
    thiserror_ext::Macro,
)]
#[thiserror_ext(
    newtype(name = MetaError, backtrace, extra_provide = Self::provide_postgres_error_code),
    macro(path = "crate::error")
)]
pub enum MetaErrorInner {
    #[error("Metadata model error: {0}")]
    MetadataModelError(
        #[from]
        #[backtrace]
        MetadataModelError,
    ),

    #[error("Hummock error: {0}")]
    HummockError(
        #[from]
        #[backtrace]
        HummockError,
    ),

    #[error(transparent)]
    RpcError(
        #[from]
        #[backtrace]
        RpcError,
    ),

    #[error("{0}")]
    PermissionDenied(String),

    #[error("Invalid worker: {0}, {1}")]
    InvalidWorker(WorkerId, String),

View on GitHub (pinned to 6469eb736d)

Solutions

1. Inspect the wrapped inner Hummock error for the concrete cause (IO, credentials, timeout).
2. Verify object-store configuration (endpoint, bucket, credentials) and connectivity from the meta/worker nodes.
3. Retry transient failures; for persistent GC/version errors, check hummock state in the meta catalog.
4. Consult storage logs on both meta and compute nodes to localize which component failed.

// Verify object-store reachability before Hummock-heavy operations
let ok = s3_client.head_bucket(BucketName).await.is_ok();
assert!(ok, "object store must be reachable before meta operations");

fn is_hummock_error(e: &MetaError) -> bool {
    matches!(e, MetaError::HummockError(_))
}

match commit_hummock_version().await {
    Err(e @ MetaError::HummockError(inner)) if is_transient(&inner) => {
        retry_with_backoff(3, || commit_hummock_version()).await?
    }
    other => other?,
}

When it happens

Trigger: Meta-side Hummock operations failing via #[from] HummockError — e.g. committing new Hummock versions, GC/compaction scheduling, or reading object metadata — typically due to S3/object-store issues or version conflicts.

Common situations: Misconfigured or unreachable object storage (wrong S3 credentials/bucket); network problems to the object store; Hummock version conflicts after node restarts; full or throttled storage backends.

Related errors

• Storage error: {0}
• Storage error: {0}
• StorageError {error}
• Metadata model error: {0}
• {0}

AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11). Data as JSON: /api/errors/ede15c39be26bf3c. Report an issue: GitHub.