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