...

A corner case is that although we don't allow static member to send LeaveGroupRequest, it is possible that broker receives a leaveGroupRequest whose `member.id` field points to a static member. This could be due to a sequence of operations like below:

1. A static member successfully joins the group.
2. Client did a restart and remove `group.instance.id` from the member consumer. (switching back to dynamic member)
3. Client won't send the LeaveGroupRequest, and the restart time was faster than session timeout.
4. The dynamic member rejoins the group without `group.instance.id`. It will be accepted since it is a known member.
5. Client did another restart. As a dynamic member, it sends LeaveGroupRequest to the broker.
6. Broker detects a LeaveGroupRequest with `member.id` attributing to a static member.

The straightforward solution will be adopted here, which is we will remove 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.

Non-goal

We do have some offline discussions on handling leader rejoin case, where due to the possible topic assignment change (adding or removing topics), we still need to start a rebalance. However since the broker could also do the subscription monitoring work, we don't actually need to trigger rebalance on leader side blindly based on its rejoin request. This is a separate topic from 345 and we are tracking the discussion in this

...