apache/kafka · error · IllegalArgumentException

Unknown compression type id: {}

Error message

Unknown compression type id: {}

What it means

Thrown by CompressionType.forId(int) when the supplied id does not match any of the five defined compression ids (0=NONE, 1=GZIP, 2=SNAPPY, 3=LZ4, 4=ZSTD). The id is the two-bit code stored in a record batch's attributes field; an unknown id cannot be decoded to a compressor, so forId raises IllegalArgumentException. Typically surfaces when the attributes byte of a record batch is itself corrupt.

Source

Thrown at clients/src/main/java/org/apache/kafka/common/record/internal/CompressionType.java:157

        this.id = id;
        this.name = name;
        this.rate = rate;
    }

    public static CompressionType forId(int id) {
        switch (id) {
            case 0:
                return NONE;
            case 1:
                return GZIP;
            case 2:
                return SNAPPY;
            case 3:
                return LZ4;
            case 4:
                return ZSTD;
            default:
                throw new IllegalArgumentException("Unknown compression type id: " + id);
        }
    }

    public static CompressionType forName(String name) {
        if (NONE.name.equals(name))
            return NONE;
        else if (GZIP.name.equals(name))
            return GZIP;
        else if (SNAPPY.name.equals(name))
            return SNAPPY;
        else if (LZ4.name.equals(name))
            return LZ4;
        else if (ZSTD.name.equals(name))
            return ZSTD;
        else
            throw new IllegalArgumentException("Unknown compression name: " + name);
    }

View on GitHub (pinned to c31c9215e1)

Solutions

1. Inspect the segment with kafka-dump-log to confirm whether the attributes byte is genuinely corrupt or signals an unsupported newer compression type.
2. If corrupt, restore the segment from a healthy replica or delete it so the log truncates to the last valid offset.
3. If the value is a legitimate new id from a newer Kafka, upgrade the client/broker to a version that knows that compression type.

// CompressionType.forId only knows ids 0..4
static final Set<Integer> KNOWN_IDS = Set.of(0, 1, 2, 3, 4);
if (!KNOWN_IDS.contains(id)) {
    throw new IllegalArgumentException("No compression type for id " + id);
}
CompressionType t = CompressionType.forId(id);

// Narrow a raw id to a valid CompressionType before use
static Optional<CompressionType> safeForId(int id) {
    return (id >= 0 && id <= 4)
        ? Optional.of(CompressionType.forId(id))
        : Optional.empty();
}

try {
    CompressionType t = CompressionType.forId(rawId);
} catch (IllegalArgumentException e) {
    // unknown wire id; default to NONE or reject the message
}

When it happens

Trigger: Calling CompressionType.forId(id) with an id outside 0..4. In practice reached by RecordBatch attribute decoding (e.g., DefaultRecordBatch.compressionType() or AbstractLegacyRecordBatch) when the attributes field's compression bits hold a value like 5, 6, or 7.

Common situations: Corrupt record-batch attributes byte (bit-flip in the compression bits); reading a non-Kafka or partially-written buffer; a future Kafka version introduces a new compression id that the running older client does not recognize (forward-compatibility break).

Related errors

• Record size %d is less than the minimum record overhead (%d)
• Unknown compression name: {}
• Illegal MetadataRecoveryStrategy: {name}
• Timeout needs to be greater than 0
• Partition {partition} was not included in the original reque

AI-assisted analysis of apache/kafka@c31c9215e1 (2026-08-03). Data as JSON: /data/errors/6047eea654cb4173.json. Report an issue: GitHub.