Hi Jun, Thanks for your response. JR23: You are absolutely correct. It seems to me that not sending a clientInstanceId in the header and explicitly sending a zero UUID as the clientInstanceId in the header can be treated as semantically equivalent. I've tweaked the words slightly.
Thanks, Andrew On 2026/05/19 03:42:16 Jun Rao via dev wrote: > Hi, Andrew, > > Thanks for the reply. > > JR23. Our message protocol doc says "Any fields in the message object that > are not present in the version that you are deserializing will be reset to > default values. Unless a custom default has been set:". Uuid fields > default to zero uuid. > So if the server gets header.clientInstanceId=0 in the deserialized header, > could it distinguish between the ID not being present (since client is old) > and the ID being explicitly set to 0 by the client? > > Jun > > > On Mon, May 18, 2026 at 7:45 PM Andrew Schofield <[email protected]> > wrote: > > > Hi Jun, > > Thanks for your reply. It's tricky squaring a circle. > > > > JR23: For GetTelemetrySubscriptions, I have changed it so that a client > > which omits the ClientInstanceId from the request header is permitted to > > specify a zero ClientInstanceId in the request body, following original > > KIP-714 precedent. However, a client which specifies a ClientInstanceId in > > the request header MUST specify the same ClientInstanceId in the request > > body. This ensures that the header and telemetry UUIDs are the same. > > > > Thanks, > > Andrew > > > > On 2026/05/12 17:48:23 Andrew Schofield wrote: > > > Hi Jun, > > > Thanks for the reply and digging into the details. > > > > > > JR23: Correct. The client telemetry component will use UUID-B as the > > client instance ID. > > > > > > JR23.1: Yes, I agree. It's not ideal. When I was drawing up the tables, > > I was thinking that this might be a possibility, but I'm less convinced > > now. I think that I should mandate that if a client specifies > > header.ClientInstanceId on GetTelemetrySubscriptions request, then > > request.ClientInstanceId must either be zero or equal to > > header.ClientInstanceId. > > > > > > JR23.2: This is perhaps the interesting one. From its original intent, > > it should be UUID-B (the telemetry UUID), but then that contradicts the > > change in signature to remove the timeout. Unless I make the change above, > > in which case it will be UUID-H. > > > > > > Thanks, > > > Andrew > > > > > > On 2026/05/12 17:23:58 Jun Rao via dev wrote: > > > > Hi, Andrew, > > > > > > > > Thanks for the reply. > > > > > > > > JR23. In the new client -> old broker case, we have > > > > header.ClientInstanceId=UUID-H > > > > request.ClientInstanceId=UUID-B > > > > response.ClientInstanceId=0 > > > > > > > > On the server side, I guess the telemetry component will use UUID-B as > > the > > > > clientInstanceId? This has a couple of implications. > > > > JR23.1 On the server side, we have two different clientInstanceIds > > used in > > > > different places, UUID-H for request logging and UUID-B in telemetry. > > This > > > > seems confusing since we can't uniquely identify a client on the server > > > > side. > > > > JR23.2 On the client side. what uuid does clientInstanceId(Duration > > > > timeout) return? If it returns UUID-H, it will be confusing since it > > > > doesn't match the ID used for telemetry on the server. > > > > > > > > Jun > > > > > > > > > > > > > > > > On Tue, May 12, 2026 at 12:58 AM Andrew Schofield < > > [email protected]> > > > > wrote: > > > > > > > > > Hi Jun, > > > > > Thanks for your response. > > > > > > > > > > JR20: I have improved (I hope) the wording. The client sends > > > > > request.clientInstanceId = 0 and header.clientInstanceId = UUID-H, > > and the > > > > > broker responds response.clientInstanceId=UUID-H. In this way, the > > broker > > > > > will have taken the UUID-H from the header, and told the client to > > use it > > > > > for client telemetry also. > > > > > > > > > > JR21: Done. Look for "henceforth". > > > > > > > > > > JR22: Summary table added. > > > > > > > > > > Thanks, > > > > > Andrew > > > > > > > > > > On 2026/05/11 19:18:24 Jun Rao via dev wrote: > > > > > > Hi, Andrew, > > > > > > > > > > > > Thanks for the reply. > > > > > > > > > > > > JR20. "If the client requests a new client instance ID on its > > initial > > > > > > GetTelemetrySubscriptions request and it sends a client instance > > ID in > > > > > the > > > > > > request header, the broker will send back that client instance ID > > rather > > > > > > than generating a new UUID. This will automatically align the UUID > > in the > > > > > > request headers and client telemetry." > > > > > > > > > > > > This seems inconsistent with what's in the table. In the table, for > > > > > > example, if the client has the following: > > > > > > GetTelemetrySubscriptions v0 > > > > > > header.ClientInstanceId = UUID-H > > > > > > request.ClientInstanceId = UUID-H > > > > > > > > > > > > or > > > > > > > > > > > > GetTelemetrySubscriptions v0 > > > > > > header.ClientInstanceId = UUID-H > > > > > > request.ClientInstanceId = UUID-R > > > > > > > > > > > > the broker returns > > > > > > response.ClientInstanceId = 0. > > > > > > > > > > > > JR21. It will be useful to document what the new client does with > > the > > > > > > returned response.ClientInstanceId. Note that return value may or > > may not > > > > > > be 0. > > > > > > > > > > > > JR22. It's probably clearer if we could populate the table with 4 > > > > > > combinations: old/new clients with old/new brokers. > > > > > > > > > > > > Jun > > > > > > > > > > > > > > > > > > > > > > > > On Fri, May 8, 2026 at 2:49 AM Andrew Schofield < > > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > Hi Jun and Chia-Ping, > > > > > > > I've overhauled part of the KIP to do with alignment of the > > request > > > > > header > > > > > > > client instance ID, client telemetry client instance ID and group > > > > > protocol > > > > > > > member IDs. The alignment is by convention, not mandate (SHOULD > > not > > > > > MUST). > > > > > > > > > > > > > > It would be possible to go around the existing RPCs such as > > > > > > > ConsumerGroupHeartbeat and GetTelemetrySubscriptions, and remove > > the > > > > > fields > > > > > > > containing the existing identifiers which are intended to be > > aligned. > > > > > Doing > > > > > > > so would be a bad idea though, because we would then have RPC > > versions > > > > > > > which essentially depend upon the presence of a tagged field in > > the > > > > > request > > > > > > > header. This is a protocol-compatibility nightmare. > > > > > > > > > > > > > > I have removed the new versions of GetTelemetrySubscriptions and > > > > > > > PushTelemetry. I have also explained the behavior of > > > > > > > GetTelemetrySubscriptions in the presence and absence of a client > > > > > instance > > > > > > > ID in the request header. > > > > > > > > > > > > > > Let me know what you think. > > > > > > > > > > > > > > Thanks, > > > > > > > Andrew > > > > > > > > > > > > > > On 2026/05/07 15:09:31 Andrew Schofield wrote: > > > > > > > > Hi Jun and Chia-Ping, > > > > > > > > I've been thinking and discussing the changes to the KIP-714 > > RPCs. > > > > > There > > > > > > > are too many combinations for my liking at the moment. I want to > > take > > > > > > > another pass at this area and will make an update in a few days. > > > > > > > > > > > > > > > > I intend to start a new vote once we have consensus because > > the spec > > > > > has > > > > > > > changed somewhat since the earliest votes. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Andrew > > > > > > > > > > > > > > > > On 2026/05/06 17:28:27 Chia-Ping Tsai wrote: > > > > > > > > > hi Andrew > > > > > > > > > > > > > > > > > > chia_0: If the consensus is to remove the "duplicate" field > > from > > > > > the > > > > > > > RPC payloads, the tagged field in the header will essentially > > become a > > > > > > > required field. This means the broker needs to handle the edge > > case > > > > > where > > > > > > > both the header and the request body have no ClientInstanceId, > > right? > > > > > If > > > > > > > so, would you mind clarifying the expected broker behavior in > > the KIP? > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > Chia-Ping > > > > > > > > > > > > > > > > > > On 2026/04/03 16:17:37 Andrew Schofield wrote: > > > > > > > > > > Hi, > > > > > > > > > > I would like to start the discussion on KIP-1313. This > > adds a > > > > > unique > > > > > > > client instance ID to the request header of all Kafka protocol > > > > > requests to > > > > > > > give a unique identifier which can be used to correlate the > > requests > > > > > from > > > > > > > each client for the purposes of problem determination. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/KAFKA/KIP-1313*3A*Client*instance*ID*in*all*request*headers__;JSsrKysrKys!!Ayb5sqE7!uqWf0-b_X82WmpmCYImD2W2rht_s_q5vHcqB9ToMV4IaeQbZF42eMJyS5XC5b5qE_qJJUj3KTCXcqEvYbwYS$ > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
