Page History

...

MEMBER_ID_MISMATCH(78, "For join group request, this implies some group.instance.id is already in the consumer group, however the member.id was not matching the record on coordinator; For leave group request, this implies the member.id list length doesn't align with group.instance.id list ", MemeberIdMisMatchException::new),
GROUP_INSTANCE_ID_NOT_FOUND(79, "Some group.instance.id specified in the leave group request are not found", GroupInstanceIdInvalidException::new)

...

RemoveMemberFromGroup (introduced above) will remove given instances and trigger rebalance immediately, which is mainly used for fast scale down/host replacement cases (we detect consumer failure faster than the session timeout). This API will first send a FindCoordinatorRequest to locate the correct broker, and initiate a LeaveGroupRequest to target broker hosting that coordinator. Within the request we add two new lists which maps from `group.instance.id` to `member.id`. The reason to include `member.id` list instead of only solely adding a `group.instance.id` list is to move LeaveGroupRequest towards a more consistent batch API in long term. The two lists are expected to be of same length and aligned, which means each `group.instance.id` at the same index of `member.id` has a strong matching in the reflected within current static membership mapon broker. The processing rules are following:

1. For each member, `group.instance.id` must be provided. A dynamic member will supply an empty string which is interpreted as UNKNOWN_GROUP_INSTANCE_ID.
2. Client could optionally provide a `member.id`. If it is provided, the member will only be removed if the `member.id` matches. Otherwise, only the `group.instance.id` is used. `Member.id` serves as a validation here, which currently will not be used (set to empty string) but potentially useful in long term when the whole removal process is automated.

The coordinator will decide whether to take this metadata change request based on its status on runtime. Error will be returned if

...

1. Unset `group.instance.id`, and change the session timeout to a smaller value if necessary
   1. For KStream user, unset `client.id` should do the work
      
2. Do a rolling bounce to switch back to dynamic membership. The dynamic member will be assigned with a new `member.id` which separates from previous generation.

 The static membership metadata stored on broker will eventually be wiped out when the corresponding `member.id` reaches session timeout. 

...

A corner case is that although we don't allow static member to send LeaveGroupRequest, the broker could still see such a scenario where the LeaveGroupRequest `member.id` points to an existing static member. The straightforward solution would be removing the member metadata all together including the static member info if this case happens. This approach ensures that downgrade process has no negative impact on the normal consumer operation, and avoids complicating the server side logic. In the long term, there could be potential use case to require static member to send LeaveGroupRequest, so we want to avoid changing the handling logic later.

...