What causes "SST {0} is invalid" in risingwavelabs/risingwave?

Verify the SST object exists in the meta SST store (hummock meta internal tables) and in the object store

risingwavelabs/risingwave · error · Error

SST {0} is invalid

Error message

SST {0} is invalid

What it means

HummockMetaError::InvalidSst indicates the meta service encountered an SSTable object ID that is not valid or does not exist in its tracked state. It is thrown when internal metadata lookups fail to find or validate an SST, typically during compaction, version deduplication, or garbage-collection logic in the Hummock storage layer.

Source

Thrown at src/meta/src/hummock/error.rs:46

    #[error("invalid hummock context {0}")]
    InvalidContext(HummockContextId),
    #[error("failed to access meta store")]
    MetaStore(
        #[source]
        #[backtrace]
        anyhow::Error,
    ),
    #[error(transparent)]
    ObjectStore(
        #[from]
        #[backtrace]
        ObjectError,
    ),
    #[error("compactor {0} is disconnected")]
    CompactorUnreachable(HummockContextId),
    #[error("compaction group error: {0}")]
    CompactionGroup(String),
    #[error("SST {0} is invalid")]
    InvalidSst(HummockSstableObjectId),
    #[error("invalid manual compaction option: {0}")]
    InvalidManualCompactionOption(String),
    #[error("invalid epoch range: {start_epoch}..={end_epoch}")]
    InvalidEpochRange { start_epoch: u64, end_epoch: u64 },
    #[error("time-travel version expired: table {table_id}, epoch {epoch}")]
    TimeTravelVersionExpired { table_id: TableId, epoch: u64 },
    #[error("time travel")]
    TimeTravel(
        #[source]
        #[backtrace]
        anyhow::Error,
    ),
    #[error(transparent)]
    Internal(
        #[from]
        #[backtrace]
        anyhow::Error,

View on GitHub (pinned to 6469eb736d)

Solutions

Verify the SST object exists in the meta SST store (hummock meta internal tables) and in the object store
Check whether a manual cleanup or GC deleted the object while it was still referenced
Restart the meta node to reload consistent version snapshots
If reproducible, file a bug with the failing SST id and meta logs — it usually indicates an internal invariant violation

Defensive patterns

Strategy: validation

Validate before calling

// Before issuing compaction/GC referencing an SST, confirm it is still tracked
if !meta_client.sst_exists(sst_id)? {
    // skip or refresh version snapshot before calling the meta API
}

Type guard

fn is_valid_sst(err: &HummockMetaError) -> bool {
    !matches!(err, HummockMetaError::InvalidSst(_))
}

Try / catch

match res {
    Err(HummockMetaError::InvalidSst(sst_id)) => warn!("SST {} vanished; refresh version and retry", sst_id),
    other => other?,
}

Prevention

Never hand-delete SST objects while versions reference them
Keep GC retention consistent across meta and object store
Re-read version snapshots after meta restarts before operating on SST ids
Monitor for object-store/meta divergence

When it happens

Trigger: Meta node internals reference an HummockSstableObjectId that is absent from the SST metadata store, e.g. during compaction task assembly or SST deletion when an SST was already removed or the version snapshot is stale.

Common situations: Corrupted or manually pruned object store state; meta/object-store divergence after a failed GC or manual cleanup; replaying stale versioned metadata; bugs in compaction scheduling referencing already-deleted SSTs.

Understand the failure class

Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.

Related errors

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