risingwavelabs/risingwave · error · SinkError

Avro error: {0}

Error message

Avro error: {0}

What it means

This is a variant of `SinkError` in RisingWave's connector crate, defined via thiserror. It wraps any `apache_avro::Error` via `#[from]`, so any failure inside the Avro serialization/deserialization machinery used by the Avro sink (or schema-registry based sinks) is surfaced as "Avro error: {0}". The original error's source and backtrace are preserved for diagnostics.

Source

Thrown at src/connector/src/sink/mod.rs:1106

#[derive(Error, Debug)]
pub enum SinkError {
    #[error("Kafka error: {0}")]
    Kafka(#[from] rdkafka::error::KafkaError),
    #[error("Kinesis error: {0}")]
    Kinesis(
        #[source]
        #[backtrace]
        anyhow::Error,
    ),
    #[error("Remote sink error: {0}")]
    Remote(
        #[source]
        #[backtrace]
        anyhow::Error,
    ),
    #[error("Encode error: {0}")]
    Encode(String),
    #[error("Avro error: {0}")]
    Avro(#[from] apache_avro::Error),
    #[error("Iceberg error: {0}")]
    Iceberg(
        #[source]
        #[backtrace]
        anyhow::Error,
    ),
    #[error("config error: {0}")]
    Config(
        #[source]
        #[backtrace]
        anyhow::Error,
    ),
    #[error("coordinator error: {0}")]
    Coordinator(
        #[source]
        #[backtrace]
        anyhow::Error,

View on GitHub (pinned to 6469eb736d)

Solutions

  1. Read the wrapped message (the `{0}` payload) — it names the exact apache-avro failure; fix the schema or data per that message.
  2. Validate the Avro schema passed to the sink: load it with `apache_avro::Schema::parse_str` locally to confirm it is valid JSON/IDL.
  3. Check that RisingWave column types match the Avro schema field types (e.g. timestamp precision, decimal scale) and adjust the schema or `encode` options.
  4. If the error arises during schema-registry interaction, verify registry connectivity and that the schema is compatible with previously registered versions under the same subject.

Example fix

-- before
CREATE SINK s FROM mv WITH (
  connector = 'kafka',
  type = '<invalid avro json>',
  ...
);
-- after
CREATE SINK s FROM mv WITH (
  connector = 'kafka',
  format = 'debezium_avro',
  type = '{"type":"record","name":"envelope","fields":[...]}',
  ...
);
Defensive patterns

Strategy: try-catch

Validate before calling

use apache_avro::Schema;
fn validate_avro_schema(schema_json: &str) -> Result<(), String> {
    Schema::parse_str(schema_json)
        .map(|_| ())
        .map_err(|e| format!("invalid avro schema: {e}"))
}

Type guard

fn as_avro_error(err: &SinkError) -> Option<&apache_avro::Error> {
    if let SinkError::Avro(e) = err { Some(e) } else { None }
}

Try / catch

match sink.write(batch).await {
    Err(SinkError::Avro(e)) => {
        log::error!("avro serialization failed: {e}");
        // inspect schema/types, then retry or poison the sink
    }
    Err(e) => return Err(e.into()),
    Ok(_) => {}
}

Prevention

When it happens

Trigger: Constructing or writing to the Avro sink: encoding a Row into Avro bytes, schema (de)registration with the schema registry, parsing the user-supplied Avro schema, or resolving/datum-conversion failures that return `apache_avro::Error`.

Common situations: Invalid user-provided Avro schema JSON in the sink's `type`/schema option; a RisingWave column type that cannot map to the declared Avro field type (type mismatch during datum conversion); schema-registry incompatibility or schema evolution conflicts (new schema not compatible with registered versions); corrupted or incompatible apache-avro crate behavior on unusual types (e.g. Decimal/Date precision).

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/be65c28fbca87f1a. Report an issue: GitHub.