You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@kafka.apache.org by "David Jacot (Jira)" <ji...@apache.org> on 2026/06/12 12:12:00 UTC

[jira] [Resolved] (KAFKA-20640) Consumer group accepts new classic members when migration policy is disabled

     [ https://issues.apache.org/jira/browse/KAFKA-20640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Jacot resolved KAFKA-20640.
---------------------------------
    Fix Version/s: 4.1.3
                   4.0.3
                   4.3.1
                   4.4.0
                   4.2.2
       Resolution: Fixed

> Consumer group accepts new classic members when migration policy is disabled
> ----------------------------------------------------------------------------
>
>                 Key: KAFKA-20640
>                 URL: https://issues.apache.org/jira/browse/KAFKA-20640
>             Project: Kafka
>          Issue Type: Bug
>    Affects Versions: 4.0.0, 4.1.0, 4.2.0, 4.3.0
>            Reporter: David Jacot
>            Assignee: Dongnuo Lyu
>            Priority: Major
>             Fix For: 4.1.3, 4.0.3, 4.3.1, 4.4.0, 4.2.2
>
>
> When group.consumer.migration.policy=disabled, a new classic-protocol member is still admitted into an existing consumer group. Because the policy permits neither an online upgrade nor an online downgrade, the group can never converge back to a single protocol — it stays permanently mixed.
> This is inconsistent with the other direction. With disabled, a new consumer-protocol member joining a classic group is refused, because the upgrade it would require is turned off. A new classic member joining a consumer group should be refused for the same reason: the downgrade it would imply is also turned off. Under disabled the intent is that no migration happens and groups stay single-protocol, so a new classic member joining a consumer group should be rejected, mirroring the consumer-into-classic case that is already rejected today.
> This applies to disabled only. Under upgrade, classic members already in the group during an in-progress upgrade must still be able to rejoin after a transient fence, and under downgrade, new classic members are the mechanism of the downgrade rollout, so neither policy should reject them.



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