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