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)
