apache/kafka · error · IllegalArgumentException
Unknown acknowledge type id: {id}
Error message
Unknown acknowledge type id: {id} What it means
Thrown by AcknowledgeType.forId(byte) when deserializing an acknowledge-type byte that is not 1 (ACCEPT), 2 (RELEASE), 3 (REJECT), or 4 (RENEW). AcknowledgeType is used by KafkaShareConsumer.acknowledge to signal acquisition-lock/disposition state on a share-group record. An unknown id means the broker returned or forwarded a value the client cannot map to a known disposition.
Source
Thrown at clients/src/main/java/org/apache/kafka/clients/consumer/AcknowledgeType.java:72
/**
* Returns the AcknowledgeType for the given identifier.
*
* @param id The identifier for the acknowledge type
* @return The corresponding AcknowledgeType
* @throws IllegalArgumentException If the ID is not recognized
*/
public static AcknowledgeType forId(byte id) {
switch (id) {
case 1:
return ACCEPT;
case 2:
return RELEASE;
case 3:
return REJECT;
case 4:
return RENEW;
default:
throw new IllegalArgumentException("Unknown acknowledge type id: " + id);
}
}
}
View on GitHub (pinned to c31c9215e1)
Solutions
- Upgrade kafka-clients to a version that supports the same share-group acknowledge semantics as the broker.
- Ensure no proxy/interceptor is rewriting share-group response payloads.
- Confirm the broker version actually supports KafkaShareConsumer and that share-group topics are not being routed through a classic consumer.
Example fix
// before: kafka-clients 3.8 (no share ack types) against broker 3.9+ // KafkaShareConsumer.acknowledge throws via forId on unknown id // after <dependency> <groupId>org.apache.kafka</groupId> <artifactId>kafka-clients</artifactId> <version>3.9.0</version> </dependency>
Defensive patterns
Strategy: try-catch
Type guard
// If you must map a raw byte back to AcknowledgeType, narrow it first:
static Optional<AcknowledgeType> safeAcknowledgeType(byte id) {
return Arrays.stream(AcknowledgeType.values()).filter(t -> t.id == id).findFirst();
} Try / catch
// AcknowledgeType.forId is normally only invoked by internal wire decoding. Application code uses the enum directly.
try {
AcknowledgeType t = AcknowledgeType.forId(rawByte);
} catch (IllegalArgumentException e) {
log.warn("Ignoring unknown acknowledge type id {} (client/broker version skew)", rawByte);
// default to ACCEPT or surface a processing error to the caller
} Prevention
- Application code should pass the AcknowledgeType enum (ACCEPT/RELEASE/REJECT/RENEW) to KafkaShareConsumer.acknowledge, never a raw byte.
- This error signals client/broker version mismatch when decoding a share-ack from the wire.
- Upgrade the client jar to match the broker when new acknowledge types appear.
When it happens
Trigger: Calling KafkaShareConsumer.acknowledge(...) where the broker responds with an acknowledge id outside 1-4, or deserializing an AcknowledgementsResponse / ShareFetch response whose commit/acknowledge byte is unrecognized. Reachable only on the share-groups code path (KIP-932).
Common situations: Client/broker version skew where the broker added a new AcknowledgeType the client does not know; an intermediate proxy or a custom serializer mangling the acknowledge byte; using an old kafka-clients version against a broker that has the share-groups feature enabled with extended ack semantics.
Related errors
- Unknown topology description status id: {id}
- Unknown rebalance protocol id: {id}
- Buffer underflow while parsing response for request with hea
- Topic {topic} was not included in the original request
- Member {member} was not included in the original request
AI-assisted analysis of apache/kafka@c31c9215e1 (2026-08-03).
Data as JSON: /data/errors/e1dc4c663a545ef5.json.
Report an issue: GitHub.