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

  1. Upgrade kafka-clients to a version that supports the same share-group acknowledge semantics as the broker.
  2. Ensure no proxy/interceptor is rewriting share-group response payloads.
  3. 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

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


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