[jira] [Updated] (KAFKA-21187) OffsetCommit returns UNKNOWN_MEMBER_ID instead of FENCED_INSTANCE_ID for replaced classic static members in a ConsumerGroup

["sanghyeok An (Jira)" <ji...@apache.org>]

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

sanghyeok An updated KAFKA-21187:
---------------------------------
    Labels:   (was: consumer group-coordinator)

> OffsetCommit returns UNKNOWN_MEMBER_ID instead of FENCED_INSTANCE_ID for replaced classic static members in a ConsumerGroup
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: KAFKA-21187
>                 URL: https://issues.apache.org/jira/browse/KAFKA-21187
>             Project: Kafka
>          Issue Type: Bug
>          Components: consumer, group-coordinator
>            Reporter: sanghyeok An
>            Assignee: sanghyeok An
>            Priority: Minor
>
> *Description*
> ConsumerGroup.validateOffsetCommit() looks up the member by memberId without first validating the current owner of groupInstanceId.
> When static member A is replaced by member B using the same instance ID, A’s member ID is removed. A subsequent non-transactional OffsetCommit from A therefore receives UNKNOWN_MEMBER_ID instead of FENCED_INSTANCE_ID.
> Under the same conditions, OffsetCommit in a ClassicGroup and classic Heartbeat in a ConsumerGroup return FENCED_INSTANCE_ID.
> *Impact*
> Upon receiving UNKNOWN_MEMBER_ID from OffsetCommit, the classic client clears its member ID and requests to rejoin. A rejoin request with an empty member ID and the same instance ID can replace the current static member B again.
> Heartbeat fencing does not always prevent this. If the commit error resets the generation first, a delayed fencing heartbeat response for the previous generation can be ignored as stale.
> *Expected Behavior*
> For replaced classic static members in a ConsumerGroup, OffsetCommit should preserve the existing static membership fencing behavior and return FENCED_INSTANCE_ID.
>  
> *NOTE*
> {{ConsumerGroup.validateOffsetCommit()}} also handles members using the new consumer protocol. The new client’s commit response handler has no dedicated handling for {{{}FENCED_INSTANCE_ID{}}}, so any additional validation must consider compatibility with both protocols.



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)