What causes "No allow_alter_on_fly fields registered for sink: {sink_name}" in risingwavelabs/risingwave?

Drop and recreate the sink with the desired field values

risingwavelabs/risingwave · error · ConnectorError

No allow_alter_on_fly fields registered for sink: {sink_name

Error message

No allow_alter_on_fly fields registered for sink: {sink_name}

What it means

Validation error from check_sink_allow_alter_on_fly_fields: the given sink has no allow_alter_on_fly field list registered in SINK_ALLOW_ALTER_ON_FLY_FIELDS, so no fields may be altered on the fly for it. JDBC is a special case reusing the connection whitelist (see TODO #24846) until sinks get a dedicated config type.

Source

Thrown at src/connector/src/allow_alter_on_fly_fields.rs:537

) -> crate::error::ConnectorResult<()> {
    // TODO(#24846): JDBC sink currently uses `()` as sink config type in `for_all_sinks!`,
    // so it cannot have an isolated key in `SINK_ALLOW_ALTER_ON_FLY_FIELDS`.
    // Reuse the JDBC entry in `CONNECTION_ALLOW_ALTER_ON_FLY_FIELDS` for now.
    // TODO(#24846): remove this special case after JDBC sink has a dedicated config type
    // and allow-alter fields are generated directly into `SINK_ALLOW_ALTER_ON_FLY_FIELDS`.
    let allowed_fields = if sink_name == JdbcSink::SINK_NAME {
        CONNECTION_ALLOW_ALTER_ON_FLY_FIELDS.get(JdbcSink::SINK_NAME)
    } else {
        // Convert sink name to the type name key
        let Some(type_name) = sink_properties::sink_name_to_config_type_name(sink_name) else {
            return Err(ConnectorError::from(anyhow::anyhow!(
                "Unknown sink connector: {sink_name}"
            )));
        };
        SINK_ALLOW_ALTER_ON_FLY_FIELDS.get(type_name)
    };
    let Some(allowed_fields) = allowed_fields else {
        return Err(ConnectorError::from(anyhow::anyhow!(
            "No allow_alter_on_fly fields registered for sink: {sink_name}"
        )));
    };
    for field in fields {
        if !allowed_fields.contains(field) {
            return Err(ConnectorError::from(anyhow::anyhow!(
                "Field '{field}' is not allowed to be altered on the fly for sink: {sink_name}"
            )));
        }
    }
    Ok(())
}

View on GitHub (pinned to 6469eb736d)

Solutions

Drop and recreate the sink with the desired field values
Upgrade RisingWave if the sink gained allow_alter_on_fly support in a newer release
Only alter fields documented as hot-alterable for the sink

Example fix

// before: ALTER SINK sk SET location = 's3://new'; -- unsupported
// after: DROP SINK sk; CREATE SINK sk FROM t WITH (connector='iceberg', location='s3://new', ...);

Defensive patterns

Strategy: validation

Validate before calling

if !SUPPORTS_ALTER_ON_FLY_SINKS.contains(&sink_name) {
    plan_recreate_sink(sink, new_fields)?;
}

Try / catch

match res {
    Err(e) if e.to_string().contains("No allow_alter_on_fly fields registered for sink") => {
        // drop and recreate the sink with new fields
    }
    other => other?,
}

Prevention

Check hot-alter support per sink before issuing ALTER SINK
Prefer recreate workflows for sinks with immutable properties
Track release notes for newly hot-alterable sink fields

When it happens

Trigger: ALTER SINK on a connector that resolves via sink_name_to_config_type_name but is absent from SINK_ALLOW_ALTER_ON_FLY_FIELDS.

Common situations: Hot-altering properties of sinks that require recreation (e.g. changing sink target) on connectors without hot-alter support; running an older RW against newer expectations.

Related errors

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