Page History

Suppose we have three consumers in the group with static instance ids: A, B, and C. Assume we have a stable group and the respective memberIds are 1, 2, and 3. So inside the group coordinator, we have the following state:
members: {A=1, B=2, C=3}
generation: 5

In fact, the consumer leader of the group is not aware of the instance ids of the members. So it sees the membership as:
members: {1, 2, 3}.
generation: 5

Now suppose that A does a rolling restart. After restarting, the coordinator will assign a new memberId to A and let it continue using the previous assignment. So we now have the following state:
members: {A=4, B=2, C=3}
generation: 5


The leader on the other hand still sees the members in the group as {1, 2, 3} because it does not know that member A restarted and was given a new memberId. Suppose that eventually something causes the group to rebalance (e.g. maybe a new topic was created).
When the leader attempts its assignment, it will see the members {2, 3, 4}. 

However, appending group.instance.id for join group response provides some benefit even for the simple partition assignors. Consider, the default range assignor, for example. Basically it works by sorting the members in the group and then assigning partition ranges to achieve balance. Suppose we have a partition with 9 partitions. If the membership were {1, 2, 3}, then the assignment would be the following:
memberId: 1, assignment: {0, 1, 2}
memberId: 2, assignment: {3, 4, 5}
memberId: 3, assignment: {6, 7, 8}

Now when the membership changes to {2, 3, 4}, then all the assignments change as well:
memberId: 2, assignment: {0, 1, 2}
memberId: 3, assignment: {3, 4, 5}
memberId: 4, assignment: {6, 7, 8}

So basically all of the assignments change even though it's the same static members. However, if we could consider the instanceId as the first sort key, then we can compute the assignment consistently even across restarts:
instanceId: A, memberId: 1, assignment: {0, 1, 2}
instanceId: B, memberId: 2, assignment: {3, 4, 5}
instanceId: C, memberId: 3, assignment: {6, 7, 8}

And after the restart:
instanceId: A, memberId: 4, assignment: {0, 1, 2}
instanceId: B, memberId: 2, assignment: {3, 4, 5}
instanceId: C, memberId: 3, assignment: {6, 7, 8}


The full benefit of static assignment can only be realized if the assignor knows the instance ids of the members in the group. It shouldn't be necessary to do anything fancy with additional metadata.