You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "sanghyeok An (Jira)" <ji...@apache.org> on 2026/08/04 00:33:00 UTC

[jira] [Commented] (KAFKA-20889) Consider rejecting empty group.instance.id values in Kafka Streams

    [ https://issues.apache.org/jira/browse/KAFKA-20889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18101535#comment-18101535 ] 

sanghyeok An commented on KAFKA-20889:
--------------------------------------

[~mjsax]
Sorry for pinging you out of the blue. 
While working on another task, I noticed that Kafka Streams accepts an empty group.instance.id, whereas a regular Kafka consumer rejects it.
Kafka Streams appends the stream thread index before consumer validation, so an empty value becomes -1, -2, and so on.
Is this behavior intentional, or should Kafka Streams reject the empty base value as well?


> Consider rejecting empty group.instance.id values in Kafka Streams
> ------------------------------------------------------------------
>
>                 Key: KAFKA-20889
>                 URL: https://issues.apache.org/jira/browse/KAFKA-20889
>             Project: Kafka
>          Issue Type: Bug
>            Reporter: sanghyeok An
>            Assignee: sanghyeok An
>            Priority: Minor
>              Labels: needs-kip, streams
>
> ConsumerConfig only permits non-empty group.instance.id values, and a regular KafkaConsumer rejects an empty value with a ConfigException.
> Kafka Streams currently appends the stream thread index before consumer validation. As a result:
> group.instance.id="" → "-1", "-2", ...
> These derived values pass validation and enable static membership. Multiple application instances may then generate the same instance IDs.
> We should consider validating the base group.instance.id before appending the thread index and rejecting empty values consistently with ConsumerConfig. Unit-test coverage should be added if this behavior is changed.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)