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