What causes "Non-zero compression {} not supported" in risingwavelabs/risingwave?

Disable compression in the producer's Glue/Avro serializer configuration so payload[1] is 0

Non-zero compression {} not supported

Error message

Non-zero compression {} not supported

What it means

This error is thrown when parsing a Glue-schema-registry-serialized Avro message whose header byte at position 1 (the compression byte) is not zero. The parser only supports uncompressed Glue payloads; any compression indicator means the payload was produced with a compression variant the parser cannot decompress, so ingestion fails fast.

Source

Thrown at src/connector/src/parser/avro/parser.rs:138

                }
            }
            WriterSchemaCache::Glue(resolver) => {
                // <https://github.com/awslabs/aws-glue-schema-registry/blob/v1.1.20/common/src/main/java/com/amazonaws/services/schemaregistry/utils/AWSSchemaRegistryConstants.java#L59-L61>
                // byte 0:      header version = 3
                // byte 1:      compression: 0 = no compression; 5 = zlib (unsupported)
                // byte 2..=17: 16-byte UUID as schema version id
                // byte 18..:   raw avro payload
                if payload.len() < 18 {
                    bail!("payload shorter than 18-byte glue header");
                }
                if payload[0] != 3 {
                    bail!(
                        "Only support glue header version 3 but found {}",
                        payload[0]
                    );
                }
                if payload[1] != 0 {
                    bail!("Non-zero compression {} not supported", payload[1]);
                }
                let schema_version_id = uuid::Uuid::from_slice(&payload[2..18]).unwrap();
                let writer_schema = resolver.get_by_id(schema_version_id).await?;
                let mut raw_payload = &payload[18..];
                Ok(Some(from_avro_datum(
                    writer_schema.as_ref(),
                    &mut raw_payload,
                    Some(&self.schema.original_schema),
                )?))
            }
        }
    }
}

#[derive(Debug, Clone)]
pub struct AvroParserConfig {
    schema: Arc<ResolvedAvroSchema>,
    /// Writer schema is the schema used to write the data. When parsing Avro data, the exactly same schema

View on GitHub (pinned to 6469eb736d)

Solutions

Disable compression in the producer's Glue/Avro serializer configuration so payload[1] is 0
If compression must stay enabled, decompress the payload before ingestion (e.g. via an intermediary) or add decompression support to the parser
Check the producer SDK version/config change history to find when compression was enabled
If this is believed to be an uncompressed payload, dump the first bytes (expect [0x03, 0x00]) to verify the header format

Example fix

// producer config (before)
GlueSchemaRegistryConfiguration cfg = new GlueSchemaRegistryConfiguration(clientProps);
cfg.compressionType = CompressionType.GZIP;
// after
cfg.compressionType = CompressionType.NONE;

Defensive patterns

Strategy: validation

Validate before calling

// producer-side guard
if (config.compressionType != CompressionType.NONE) throw new IllegalArgumentException("RisingWave Glue Avro source requires uncompressed payloads");

Try / catch

match res { Err(e) if e.to_string().contains("Non-zero compression") => alert_producer_compression_enabled(e), Err(e) => propagate(e), Ok(v) => v }

Prevention

Keep Glue serializer compression disabled for streams consumed by RisingWave
Pin serializer config in code review; watch for SDK defaults enabling compression
Add a consumer-side test that asserts the first two payload bytes are [3, 0]

When it happens

Trigger: Consuming a Glue SR Avro topic where the producer enabled compression (GZip/Zstd/etc. per the Glue header spec); payload[0]==3 passes the version check but payload[1]!=0.

Common situations: Producer application or Glue serializer configured with compression enabled; a change on the producer side switched on compression after the RW source was created; SDK default serialization settings differing from expected.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

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