risingwavelabs/risingwave · error · SinkError::Remote

remote sink supports Int16, Int32, Int64, Float32, Float64,

Error message

remote sink supports Int16, Int32, Int64, Float32, Float64, Boolean, Decimal, Time, Date, Interval, Jsonb, Timestamp, Timestamptz, Bytea, List and Varchar, (Es sink support Struct) got {:?}: {:?}

What it means

The catch-all branch of remote sink column validation: any column of type Vector, Serial, Int256, Map, or Variant is rejected because the JVM remote sink protocol cannot serialize these types. Only the listed primitive, temporal, JSONB, Bytea, List, and Varchar types are accepted (plus Struct for Es sinks).

Source

Thrown at src/connector/src/sink/remote.rs:235

                        "Remote sink only supports list<int16, int32, int64, float, double, varchar>, got {:?}: {:?}",
                        col.name,
                        col.data_type,
                    )))
                }
            },
            DataType::Struct(_) => {
                if is_remote_es_sink(sink_name){
                    Ok(())
                }else{
                    Err(SinkError::Remote(anyhow!(
                        "Only Es sink supports struct, got {:?}: {:?}",
                        col.name,
                        col.data_type,
                    )))
                }
            },
            DataType::Vector(_) |
            DataType::Serial | DataType::Int256 | DataType::Map(_) | DataType::Variant => Err(SinkError::Remote(anyhow!(
                            "remote sink supports Int16, Int32, Int64, Float32, Float64, Boolean, Decimal, Time, Date, Interval, Jsonb, Timestamp, Timestamptz, Bytea, List and Varchar, (Es sink support Struct) got {:?}: {:?}",
                            col.name,
                            col.data_type,
                        )))}})?;

    let jvm = Jvm::get_or_init()?;
    let sink_param = param.to_proto();

    spawn_blocking(move || -> anyhow::Result<()> {
        execute_with_jni_env(jvm, |env| {
            let validate_sink_request = ValidateSinkRequest {
                sink_param: Some(sink_param),
            };
            let validate_sink_request_bytes =
                env.byte_array_from_slice(&Message::encode_to_vec(&validate_sink_request))?;

            let validate_sink_response_bytes = call_static_method!(
                env,

View on GitHub (pinned to 6469eb736d)

Solutions

Drop or exclude the unsupported column from the sink's SELECT list.
Cast the column to a supported type (e.g. SERIAL -> INT64, MAP -> JSONB/VARCHAR, VARIANT -> JSONB).
Flatten Map/Variant content into supported primitive columns.
Choose a native (non-JVM-remote) sink connector that supports the type if available.

Example fix

-- before
CREATE SINK s AS SELECT id, vec FROM embeddings WITH (connector='jdbc', ...);
-- after (exclude or cast)
CREATE SINK s AS SELECT id FROM embeddings WITH (connector='jdbc', ...);

Defensive patterns

Strategy: validation

Validate before calling

-- list unsupported column types before sinking
SELECT column_name, data_type
FROM rw_catalog.rw_columns
WHERE relation_id = 'your_mv_id'
  AND data_type ~ 'vector|serial|int256|map|variant';

Prevention

Avoid SERIAL/VECTOR/MAP/VARIANT columns in sink source queries; cast or exclude them
Document the remote sink's supported type list in your team's sink templates
Cast SERIAL to BIGINT and MAP/VARIANT to JSONB in the sink's SELECT

When it happens

Trigger: CREATE SINK (remote/JVM sink) where the source table or materialized view contains a column of type VECTOR, SERIAL, INT256 (hugeint-extended), MAP, or VARIANT.

Common situations: Sinking a table with an auto-generated SERIAL/identity column; sinking VECTOR columns from AI/embedding workloads; sinking MAP columns built with map_from_arrays; sinking VARIANT columns from semi-structured JSON.

Related errors

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