Hi, David, Thanks for the updated KIP. A few more comments.
90. ConsumerGroupTargetAssignmentMemberValue: 90.1 Do we need to include MemberId here given that it's in the key already? 90.2 Since there is no new record if the new member assignment is the same, it seems that AssignmentEpoch doesn't always reflect the correct assignment epoch? If so, do we still need this field? Could we just depend on ConsumerGroupTargetAssignmentMetadataValue.AssignmentEpoch? 91. "The AssignmentEpoch corresponds to the group epoch used to compute the assignment. It is not necessarily the last one." Could you explain what "It is not necessarily the last one." means? Thanks, Jun On Mon, Oct 24, 2022 at 7:49 AM Magnus Edenhill <mag...@edenhill.se> wrote: > Hi, one minor comment on the latest update: > > > Den mån 24 okt. 2022 kl 16:26 skrev David Jacot > <dja...@confluent.io.invalid > >: > > > * Jason pointed out that the member id handling is a tad weird. The > > group coordinator generates the member id and then trusts the member > > when it rejoins the group. This also implies that the client could > > directly generate its member id and the group coordinator will accept > > it. It seems better to directly let the client generate id instead of > > relying on the group coordinator. I have updated the KIP in this > > direction. Note that the new APIs still use a string for the member id > > in order to remain consistent with the existing APIs. > > > > We had a similar discussion for id generation in KIP-714 and I'd advise > against client-side id generation for a couple of reasons: > - it is much more likely for the client side prng to be poorly seeded, or > incorrectly implemented, than the server side. > This risks two different consumer instances generating the same id. > - it adds an extra dependency on the client, a uuid library/module, which > brings with it the usual plethora > of linking conflicts, package availability issues, etc. > - as for trusting the authenticity of the id; with server-side generation > we at least have a (future) possibility for verifying the id, would it ever > become an issue. > > > Regards, > Magnus >
