risingwavelabs/risingwave · warning · AccessError

Unsupported additional column

Error message

Unsupported additional column `{name}`

What it means

AccessError::UnsupportedAdditionalColumn in src/connector/codec/src/decoder/mod.rs:43. Thrown when a decoder encounters an additional/unexpected column `name` in the payload that is not part of the declared schema and cannot be accepted (e.g. strict decoding where extra fields are rejected).

Solutions

  1. Update the RisingWave source/table schema to include the new column (recreate the source or rely on auto schema change)
  2. Remove the extra field at the producer/transform layer (e.g. drop the SMT or use DropFields)
  3. If the field is metadata, configure the connector to ignore unknown envelope fields
  4. Check `name` in the error to identify exactly which column leaked in

Example fix

// before (Kafka Connect SMT)
"transforms.insertField.type": "org.apache.kafka.connect.transforms.InsertField$Value"
// after: drop the transform or drop the field before ingestion
Defensive patterns

Strategy: validation

Validate before calling

fn no_extra_columns(payload_keys: &[&str], declared: &[&str]) -> Vec<String> {
    payload_keys.iter()
        .filter(|k| !declared.contains(k))
        .map(|k| k.to_string())
        .collect()
}

Prevention

When it happens

Trigger: Decoding a record (Debezium/Protobuf/JSON path) where the payload contains a field absent from the RW schema and the access path forbids additional columns; often in CDC auto-schema-change checks deciding whether a new column can be handled.

Common situations: Upstream schema evolved to add a new column while RisingWave's source definition was not updated; producers including internal/envelope fields (e.g. new Debezium metadata keys) not anticipated; connect transforms adding fields (e.g. InsertField SMT).

Understand the failure class

Background: Schema validation failed / invalid input schema: payload rejected because its shape doesn't match the expected schema — this error's family across 28 libraries.

Related errors


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

Appendix: source

Thrown at src/connector/codec/src/decoder/mod.rs:43

#[derive(Error, Debug, Macro)]
#[thiserror_ext(macro(mangle, path = "crate::decoder"))]
pub enum AccessError {
    #[error("Undefined field `{name}` at `{path}`")]
    Undefined { name: String, path: String },
    #[error("Cannot parse value `{value}` with type `{got}` into expected type `{expected}`")]
    TypeError {
        expected: String,
        got: String,
        value: String,
    },
    #[error("Unsupported data type `{ty}`")]
    UnsupportedType { ty: String },

    /// CDC auto schema change specific error that may include table context
    #[error("CDC auto schema change error: unsupported data type `{ty}` in table `{table_name}`")]
    CdcAutoSchemaChangeError { ty: String, table_name: String },

    #[error("Unsupported additional column `{name}`")]
    UnsupportedAdditionalColumn { name: String },

    #[error("Fail to convert protobuf Any into jsonb: {0}")]
    ProtobufAnyToJson(#[source] serde_json::Error),

    /// Parquet parser specific errors
    #[error("Parquet parser error: {message}")]
    ParquetParser { message: String },

    /// Errors that are not categorized into variants above.
    #[error("{message}")]
    Uncategorized { message: String },

    #[error(transparent)]
    NotImplemented(#[from] NotImplemented),
    // NOTE: We intentionally don't embed `anyhow::Error` in `AccessError` since it happens
    // in record-level and it might be too heavy to capture the backtrace
    // when creating a new `anyhow::Error`.

View on GitHub (pinned to 6469eb736d)