risingwavelabs/risingwave · error

{} unsupported in {} catalog

Error message

{} unsupported in {} catalog

What it means

Inside JNI catalog config building, non-S3/Glue object-store backend properties are only valid with a REST catalog. The `require_rest` closure bails with `'{backend} unsupported in {catalog_type} catalog'` when such a backend option is set for hive, snowflake, jdbc, or glue catalogs.

Source

Thrown at src/connector/src/connector_common/iceberg/mod.rs:779

    }

    /// For both V1 and V2.
    fn build_jni_catalog_configs(
        &self,
        catalog_impl: JniCatalogImpl,
        java_catalog_props: &HashMap<String, String>,
    ) -> ConnectorResult<(HashMap<String, String>, HashMap<String, String>)> {
        let mut iceberg_configs = HashMap::new();
        let enable_config_load = self.enable_config_load();
        let file_io_props = {
            let catalog_type = catalog_impl.catalog_type();

            // Non-S3/Glue object-store backends only work with a REST catalog. This
            // function is only invoked for catalog_type in {hive, snowflake, jdbc, rest,
            // glue}, so the only accepted value here is "rest".
            let require_rest = |backend: &str| -> ConnectorResult<()> {
                if catalog_impl != JniCatalogImpl::Rest {
                    bail!("{} unsupported in {} catalog", backend, catalog_type);
                }
                Ok(())
            };

            if let Some(region) = &self.s3_region {
                // iceberg-rust
                iceberg_configs.insert(S3_REGION.to_owned(), region.clone());
            }

            if let Some(endpoint) = &self.s3_endpoint {
                // iceberg-rust
                iceberg_configs.insert(S3_ENDPOINT.to_owned(), endpoint.clone());
            }

            // iceberg-rust
            if let Some(access_key) = &self.s3_access_key {
                iceberg_configs.insert(S3_ACCESS_KEY_ID.to_owned(), access_key.clone());
            }

View on GitHub (pinned to 6469eb736d)

Solutions

  1. Switch to `catalog.type = 'rest'` if you need that object-store backend.
  2. Remove the unsupported backend properties when using a non-REST catalog and rely on S3-backed Glue/Hive instead.
  3. Consult the connector docs for the backend/catalog compatibility matrix.

Example fix

// before
with ( connector='iceberg', catalog.type='glue', gcs.service.account='...' )
// after
with ( connector='iceberg', catalog.type='rest', catalog.uri='...', gcs.service.account='...' )
Defensive patterns

Strategy: validation

Validate before calling

const NON_S3_BACKEND_OPTS = ['gcs.service.account','oss.*','azblob.*'];
if (catalogType !== 'rest' && Object.keys(opts).some(k => NON_S3_BACKEND_OPTS.some(p => new RegExp('^'+p).test(k)))) {
  throw new Error(`backend option unsupported in ${catalogType} catalog; use catalog.type='rest'`);
}

Try / catch

catch (e) { if (/unsupported in .* catalog$/.test(String(e))) { /* either drop the backend option or switch catalog.type to 'rest' */ } else { throw e; } }

Prevention

When it happens

Trigger: Setting e.g. gcs/oss/azblob backend options (any backend where `require_rest` is invoked) while `catalog.type` is 'hive', 'snowflake', 'jdbc', or 'glue' — anything other than 'rest'.

Common situations: Users on GCS/Azure trying to use the Hive or Glue catalog; mixing backend props copied from a REST-catalog example into another catalog type.

Understand the failure class

Background: Conflicting config options: "cannot be used together" — configuration validation errors across open-source libraries — this error's family across 162 libraries.

Related errors


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