risingwavelabs/risingwave · error · MetaError

only the table, sink, subscription, view and index will…

Error message

only the table, sink, subscription, view and index will depend on other objects.

What it means

During object rename, the transactional helper only knows how to update dependent rows for tables, sinks, subscriptions, views and indexes; any other dependent object type hits the `_` arm and bails with "only the table, sink, subscription, view and index will depend on other objects.". It marks an unsupported rename dependency rather than silently skipping reference updates.

Solutions

1. Add a match arm (or reuse the `rename_relation_ref!` macro) for the unsupported dependent type so references are updated during rename.
2. Avoid renaming objects that are referenced by unsupported dependent types; drop and recreate with the new name instead.
3. Upgrade meta to a version whose rename path covers the object types present in your cluster.
4. Inspect the operation's object types to confirm which dependent type fell through, and extend tests for that rename path.

Example fix

// before
_ => bail!("only the table, sink, subscription, view and index will depend on other objects."),
// after
Schema => { rename_schema_ref!(...); }
_ => bail!("only the table, sink, subscription, view and index will depend on other objects."),

// Restrict rename to supported dependent types
if !matches!(dep_type, Table | Sink | Subscription | View | Index) {
    return Err("rename unsupported for this dependent object type");
}

When it happens

Trigger: Renaming an object (e.g. via ALTER ... RENAME or the rename path in utils.rs) where a dependent relation of an unsupported type references it — the match over the dependent object's type falls through to the default arm.

Common situations: Adding a new relation type without extending the rename logic; internal/automated rename of an exotic object; version skew between components creating dependencies the rename code does not cover.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

• failed to parse relation definition
• should contains only one statement
• unsupported job type for replacement
• id not found
• named already exists

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

Appendix: source

Thrown at src/meta/src/controller/utils.rs:2271

                rename_relation_ref!(
                    Subscription,
                    subscription,
                    subscription_id,
                    obj.oid.as_subscription_id()
                )
            }
            ObjectType::View => rename_relation_ref!(View, view, view_id, obj.oid.as_view_id()),
            ObjectType::Index => {
                let index_table_id: Option<TableId> = Index::find_by_id(obj.oid.as_index_id())
                    .select_only()
                    .column(index::Column::IndexTableId)
                    .into_tuple()
                    .one(txn)
                    .await?;
                rename_relation_ref!(Table, table, table_id, index_table_id.unwrap());
            }
            _ => {
                bail!(
                    "only the table, sink, subscription, view and index will depend on other objects."
                )
            }
        }
    }

    Ok(to_update_relations)
}

/// Validate that subscription can be safely deleted, meeting any of the following conditions:
/// 1. The upstream table is not referred to by any cross-db mv.
/// 2. After deleting the subscription, the upstream table still has at least one subscription.
pub async fn validate_subscription_deletion<C>(
    txn: &C,
    subscription_id: SubscriptionId,
) -> MetaResult<()>
where
    C: ConnectionTrait,

View on GitHub (pinned to 6469eb736d)