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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
