risingwavelabs/risingwave · error

table {} doesn't belong to any compaction group, skip trunca

Error message

table {} doesn't belong to any compaction group, skip truncating

What it means

During commit_epoch, when the caller requests table truncation alongside the commit, every listed table must be mapped to a compaction group. If a table id has no entry in table_compaction_group_mapping, commit_epoch aborts with this bail rather than silently skipping truncation for that table.

Source

Thrown at src/meta/src/hummock/manager/commit_epoch.rs:225

                    .compaction_config();
                group_id_to_config.insert(*cg_id, compaction_group);
            }
        }

        let group_id_to_sub_levels =
            rewrite_commit_sstables_to_sub_level(commit_sstables, &group_id_to_config);

        // build group_id to truncate tables
        let mut group_id_to_truncate_tables: HashMap<CompactionGroupId, HashSet<TableId>> =
            HashMap::new();
        for table_id in &truncate_tables {
            if let Some(compaction_group_id) = table_compaction_group_mapping.get(table_id) {
                group_id_to_truncate_tables
                    .entry(*compaction_group_id)
                    .or_default()
                    .insert(*table_id);
            } else {
                bail!(
                    "table {} doesn't belong to any compaction group, skip truncating",
                    table_id
                );
            }
        }

        let time_travel_delta = version.pre_commit_epoch(
            &tables_to_commit,
            new_compaction_groups,
            group_id_to_sub_levels,
            &new_table_ids,
            new_table_watermarks,
            change_log_delta,
            vector_index_delta,
            group_id_to_truncate_tables,
        );

        if should_mark_next_time_travel_version_snapshot(&time_travel_delta) {

View on GitHub (pinned to 6469eb736d)

Solutions

  1. Check whether the table was dropped or reassigned and remove it from the truncation list
  2. Refresh the compaction-group mapping (list hummock compaction groups) and retry the commit with valid tables
  3. Retry the operation — transient races with group re-assignment may resolve
  4. If the mapping is persistently missing for a live table, this is an internal inconsistency: inspect meta tables and report a bug
Defensive patterns

Strategy: try-catch

Validate before calling

// Caller-side: filter out tables with no compaction group before requesting truncation
let valid: Vec<_> = table_ids.into_iter().filter(|t| group_mapping.contains_key(t)).collect();

Type guard

fn all_tables_mapped(tables: &[TableId], mapping: &HashMap<TableId, CompactionGroupId>) -> bool {
    tables.iter().all(|t| mapping.contains_key(t))
}

Try / catch

match commit_epoch(new_epoch, ssts, truncate_tables).await {
    Err(e) if e.to_string().contains("doesn't belong to any compaction group") => {
        tracing::warn!("stale table in truncation list; refresh mapping and retry: {e}");
    }
    other => other?,
}

Prevention

When it happens

Trigger: commit_epoch invoked with truncate-tables/retention request where one of the listed table ids is missing from the group mapping fetched from the compaction group manager (e.g. table just dropped, or mapping not yet assigned).

Common situations: Race between dropping a table and a commit that still lists it for truncation; meta state where table-group assignment was lost; clients (frontend/risectl) caching stale table ids after the table was removed.

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

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