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
- Read the wrapped message (the `{0}` payload) — it names the exact apache-avro failure; fix the schema or data per that message.
- Validate the Avro schema passed to the sink: load it with `apache_avro::Schema::parse_str` locally to confirm it is valid JSON/IDL.
- Check that RisingWave column types match the Avro schema field types (e.g. timestamp precision, decimal scale) and adjust the schema or `encode` options.
- 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
- Validate the Avro schema with apache_avro::Schema::parse_str before creating the sink.
- Keep RisingWave column types aligned with Avro schema field types (decimal scale, timestamp precision).
- When evolving schemas, ensure backward compatibility with versions registered in the schema registry.
- Pin and test against the apache-avro crate version RisingWave uses when doing local repro.
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
- avro parse unexpected eof
- should have meta client
- should get metadata on checkpoint barrier
- newly start epoch {} after update vnode bitmap not matched w
- cannot serialize Document to Vec<u8>
AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11).
Data as JSON: /api/errors/be65c28fbca87f1a.
Report an issue: GitHub.