risingwavelabs/risingwave · error · MetaError

unexpected referring object type: {}

Error message

unexpected referring object type: {}

What it means

`validate_restrict_drop_and_collect_owned_objects` walks objects that refer to the object being dropped to enforce RESTRICT semantics. Only table, source, sink, subscription, view, connection and index are known to depend on other objects; if `drop_object` hands it any other object type, the function bails with "unexpected referring object type: {}". This is an internal exhaustiveness guard over the object-type dispatch.

Source

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

                }
                ObjectType::Connection => {
                    let connections: Vec<(String, String)> = Object::find()
                        .join(JoinType::InnerJoin, object::Relation::Connection.def())
                        .join(JoinType::InnerJoin, object::Relation::Database2.def())
                        .join(JoinType::InnerJoin, object::Relation::Schema2.def())
                        .select_only()
                        .column(schema::Column::Name)
                        .column(connection::Column::Name)
                        .filter(object::Column::Oid.is_in(objs.iter().map(|o| o.oid)))
                        .into_tuple()
                        .all(db)
                        .await?;
                    details.extend(connections.into_iter().map(|(schema_name, view_name)| {
                        format!("connection {}.{} depends on it", schema_name, view_name)
                    }));
                }
                // only the table, source, sink, subscription, view, connection and index will depend on other objects.
                _ => bail!("unexpected referring object type: {}", obj_type.as_str()),
            }
        }
        if details.is_empty() {
            return Ok(referring_objects);
        }

        return Err(MetaError::permission_denied(format!(
            "{} used by {} other objects. \nDETAIL: {}\n\
            {}",
            object_type.as_str(),
            details.len(),
            details.join("\n"),
            match object_type {
                ObjectType::Function | ObjectType::Connection | ObjectType::Secret =>
                    "HINT: DROP the dependent objects first.",
                ObjectType::Database | ObjectType::Schema => unreachable!(),
                _ => "HINT:  Use DROP ... CASCADE to drop the dependent objects too.",
            }

View on GitHub (pinned to 6469eb736d)

Solutions

1. Extend the match in `validate_restrict_drop_and_collect_owned_objects` with an arm for the new object type, collecting its referring objects like the existing arms.
2. If you are a user hitting this at runtime, upgrade meta and frontend to matching versions so both sides know the object type.
3. Check `obj_type.as_str()` in the message to identify the unhandled kind and confirm it is expected; if not, file/inspect how it got created.
4. As a workaround, drop the depending objects first manually so validation takes the supported path.

Example fix

// before
_ => bail!("unexpected referring object type: {}", obj_type.as_str()),
// after
ObjectType::Function => { /* collect referring objects for functions */ }
_ => bail!("unexpected referring object type: {}", obj_type.as_str()),

// Only drop object types the validation path supports
const SUPPORTED: &[ObjectType] = &[Table, Source, Sink, Subscription, View, Connection, Index];
assert!(SUPPORTED.contains(&obj_type), "unsupported referring type: {:?}", obj_type);

When it happens

Trigger: Calling `drop_object` (directly or via the metadata RPC) on an object type not in the handled set while it is used as a referring object — i.e. the match arms were not extended when a new object kind was added to the catalog.

Common situations: Development after adding a new catalog object type without updating the drop-validation match; internal tooling invoking drop validation with an unexpected `ObjectType`; version skew where a newer frontend/meta creates object kinds the current validation code does not know.

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

• iceberg pk-index writer input must be a merge after actor re
• snapshot backfill epoch set again: {} {} {}
• LogStore row sequential scan should not have input executor!
• MergeSortExchangeExecutor should not have child!
• Row sequential scan should not have input executor!

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