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
