risingwavelabs/risingwave · error · AccessError

Unsupported data type `{ty}`

Error message

Unsupported data type `{ty}`

What it means

AccessError::UnsupportedType in src/connector/codec/src/decoder/mod.rs:36. Thrown when the schema/decoder encounters a data type it does not support converting for the given encoding, carrying the unsupported type name `ty`.

Source

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

pub mod utils;

use risingwave_common::error::NotImplemented;
use risingwave_common::types::{DataType, Datum, DatumCow, ToOwnedDatum};
use thiserror::Error;
use thiserror_ext::Macro;

#[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}")]

View on GitHub (pinned to 6469eb736d)

Solutions

1. Change the upstream field type to one supported by RisingWave's encoder mapping (scalar types, structs, supported arrays)
2. Map the unsupported type at the producer side (e.g. serialize duration as BIGINT microseconds)
3. Read `ty` from the error, check RisingWave's supported type list for the encoding, and adjust the table schema accordingly
4. Upgrade RisingWave — newer versions extend type coverage

Example fix

// before (Avro)
{"name": "interval", "type": {"type": "fixed", "size": 12, "logicalType": "duration"}}
// after
{"name": "interval_micros", "type": "long"}

const SUPPORTED: &[&str] = &["boolean","integer","bigint","real","double","varchar","date","timestamp","struct","array"];
fn type_supported(ty: &str) -> bool { SUPPORTED.contains(&ty) }

When it happens

Trigger: Decoding payloads whose schema contains type declarations outside the supported set for that decoder path — e.g. Avro/Protobuf/Debezium types that have no RisingWave mapping (complex unions, nested arrays of arrays in certain encodings, unknown logical types).

Common situations: Upstream added a new field with an exotic type (e.g. Avro `duration` logical type, Protobuf `Any`/`oneof` in an unsupported spot); CDC payloads with Debezium types not mapped by the Debezium→RW converter; upgrading a producer SDK that emits newer type descriptors.

Related errors

• {message}
• unsupported data type: {}, set to null
• unsupported PostgreSQL snapshot data type {data_type} for co
• REAL is not supported for BigQuery sink. Please convert to F
• VARIANT is not supported for BigQuery sink.

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