risingwavelabs/risingwave · critical

state table {} is not registered to hummock

Error message

state table {} is not registered to hummock

What it means

validate_database_info requires every state table referenced by a fragment to be registered in state_table_committed_epochs (i.e. known to Hummock with a committed epoch). A fragment referencing an unregistered state table aborts recovery, since such a table cannot be read from or written to safely.

Source

Thrown at src/meta/src/barrier/mod.rs:182

                for (actor_id, actor) in &fragment.actors {
                    if !active_streaming_nodes
                        .current()
                        .contains_key(&actor.worker_id)
                    {
                        return Err(anyhow!(
                            "worker_id {} for actor {} does not exist",
                            actor.worker_id,
                            actor_id
                        )
                        .into());
                    }
                    if !stream_actors.contains_key(actor_id) {
                        return Err(anyhow!("cannot find StreamActor of actor {}", actor_id).into());
                    }
                }
                for state_table_id in &fragment.state_table_ids {
                    if !state_table_committed_epochs.contains_key(state_table_id) {
                        return Err(anyhow!(
                            "state table {} is not registered to hummock",
                            state_table_id
                        )
                        .into());
                    }
                }
            }
            for (job_id, fragments) in database_jobs {
                let mut committed_epochs =
                    InflightFragmentInfo::existing_table_ids(fragments.values()).map(|table_id| {
                        (
                            table_id,
                            *state_table_committed_epochs
                                .get(&table_id)
                                .expect("checked exist"),
                        )
                    });
                let (first_table, first_epoch) = committed_epochs.next().ok_or_else(|| {

View on GitHub (pinned to 6469eb736d)

Solutions

1. Retry recovery; if the table registration barrier never committed, rebuild/recreate the affected job
2. Verify hummock metadata contains the table and repair registration if possible
3. Check for version checkpoint corruption and roll back to a consistent snapshot
4. File a bug; fragments must never reference unregistered state tables

let unregistered: Vec<_> = fragments.iter()
    .flat_map(|f| f.state_table_ids.iter())
    .filter(|t| !state_table_committed_epochs.contains_key(*t))
    .collect();
if !unregistered.is_empty() { return Err(format!("tables not in hummock: {:?}", unregistered)); }

if e.to_string().contains("is not registered to hummock") {
    recreate_job_from_source(job_id)?; // rebuild tables and registration
}

When it happens

Trigger: Recovery where fragment.state_table_ids contains a table missing from the Hummock-registered state table epoch map — e.g. the table was never registered due to a failed barrier, or metadata divergence between stream graph and Hummock.

Common situations: Crash between fragment creation and Hummock registration; hummock version checkpoint missing the table; bugs in table registration during job creation.

Understand the failure class

Background: "Not found" and "does not exist" errors: why "Task not found", "No such folder", and "Can't find" fire when a lookup comes back empty — this error's family across 14 libraries.

Related errors

• job {} in database {} has no state table after recovery
• job {} in database {} has tables with different table ids. {
• inconsistent hummock version: expected {}, actual {}
• since_timestamp requires at least one upstream table
• The cluster is recovering

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