[jira] [Created] (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>]

sanghyeok An created KAFKA-21187:
------------------------------------

             Summary: 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
            Reporter: sanghyeok An
            Assignee: sanghyeok An


*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
(v8.20.10#820010)