In my opinion, the main downside of this approach is that if you leave after receiving the first HB and the member id, the server will respond with an unknown member id error because the member is not really in the group yet.
I don't want to be a hater of idempotent HB, but having a "RPC" used to generate UUID is unnecessary to me. In the proposed changes section, we should elaborate the uuid generation part. Do we have recommendations there? Do we have requirements for the uuid (version, uniqueness, etc.)? I'm not sure whether it is worth requiring the UUID format for member id. In the protocol, we declare the field "memberId" as "String" rather than "uuid". The scope of member id is in "a group", so I guess the collision won't be a big issue. For another, I always wonder why we trust clients to generate "unique" transaction id but we worry about generating "unique" member id on client side? Best, Chia-Ping
