Re: [DISCUSS] KIP-1313: Client instance ID in all request headers

[Jun Rao via dev <de...@kafka.apache.org>]

Hi, Andrew,

Thanks for the reply.

JR37. Will it be better to require ClientInstanceId only on the first
request, to be consistent with clientId?

JR38. "must specify a non-zero client instance ID". one_uuid is also a
reserved one in the Uuid class. Should we exclude that one too?

Jun

On Fri, Jul 31, 2026 at 9:10 AM Andrew Schofield <sc...@apache.org>
wrote:

> Hi Jun,
> Thanks for the reply and sorry for the delay. Lots of 4.4 stuff got in the
> way.
>
> JR34: EligibleLeaderReplicasVersion and KRaftVersion also use ApiVersion
> to negotiate the RPC versions. I do not believe we need to bump up other
> feature versions as a result of the RPC version bumps in this KIP.
>
> JR35: Yes, good catch. In order to handle client ID-based quotas for
> forwarded requests, it will be necessary to populate the client ID in the
> forwarded request header. KIP updated.
>
> JR36: I hadn't considered MV to be a feature version, but I understand.
> KIP updated.
>
> Thanks,
> Andrew
>
> On 2026/06/29 16:23:09 Jun Rao via dev wrote:
> > Hi, Andrew,
> >
> > Thanks for the reply.
> >
> > JR34. Transaction coordinator uses ApiVersion to negotiate the PRC
> > versions. Therefore, if there is no functional change, there is no need
> to
> > bump the TV version. I am not sure about EligibleLeaderReplicasVersion
> > and KRaftVersion.
> > It would be useful to have the experts chime in.
> >
> > JR35. Envelope/forwarding interaction: When a broker forwards a client
> > request to the controller via EnvelopeUtils
> (parseForwardedRequestHeader),
> > the inner header may have its clientId optimized to null. Some quota
> > enforcement (e.g. controller mutation) may depend on the non-null
> clientId.
> > The per-connection caching occurs on the original client↔broker
> connection, not
> > the broker↔controller one. Should the forwarded request preserve the
> > non-null resolved (cached) client.id?
> >
> > JR36. "This KIP does not need to introduce any feature version bumps."
> This
> > is not very accurate since MV is a feature version and is bumped.
> >
> > Jun
> >
> >
> > On Fri, Jun 26, 2026 at 12:42 AM Andrew Schofield <schofielaj@apache.org
> >
> > wrote:
> >
> > > Hi Jun,
> > > I've updated the KIP.
> > >
> > > JS34: I don't believe that we need to introduce any new feature
> versions
> > > for this KIP. For example, we do not need a new ShareVersion since that
> > > enabled share groups (SV_1) and controls the versioning of the records
> on
> > > the internal topics (SV_2). I think the same applies for the others. I
> > > understand GroupVersion and StreamsVersion, and I think they follow the
> > > same reasoning as ShareVersion. I don't know TransactionVersion or
> > > EligibleLeaderReplicasVersion, so let me know whether those are
> different
> > > in this regard.
> > >
> > > Thanks,
> > > Andrew
> > >
> > > On 2026/06/25 21:32:27 Andrew Schofield wrote:
> > > > Hi Jun,
> > > > Thanks for the reply.
> > > >
> > > > JR27: Yes, makes sense. So request header v3 is binary-compatible
> with
> > > request header v2.
> > > >
> > > > JS34: Yes, I think so.
> > > >
> > > > I'll update the KIP tomorrow morning.
> > > >
> > > > Thanks,
> > > > Andrew
> > > >
> > > > On 2026/06/25 20:23:57 Jun Rao via dev wrote:
> > > > > Hi, Andrew,
> > > > >
> > > > > Thanks for the reply.
> > > > >
> > > > > JR27. I was thinking of the following, which is slightly different
> from
> > > > > what you described.
> > > > > * Bump RequestHeader to v3, and introduce ClientInstanceId as a
> tagged
> > > > > field for versions 3+ and change the semantic of the existing field
> > > > > clientId (only need to be populated by the first request).
> > > > > * Bump the request versions for all RPCs including ApiVersion and
> map
> > > to
> > > > > the new version to use v3 of RequestHeader.
> > > > > * On the server side, when a new request version is seen, we
> enforce
> > > the
> > > > > presence of ClientInstanceId and reject the request if it is
> missing.
> > > > > Essentially, treat it as a required field. We also cache the
> clientId
> > > from
> > > > > the first request and ignore it from subsequent ones.
> > > > > * We would introduce OffsetDelete v1 as the first flexible version
> so
> > > that
> > > > > it uses the v3 request header.
> > > > > * We would update PushTelemetry and GetTelemetrySubscriptions as
> > > described
> > > > > in the KIP and the ClientInstanceId would move to the request
> header.
> > > > >
> > > > > In the future, if we want to add a new truly optional field to
> > > > > RequestHeader, we can continue adding it as a tagged field without
> > > bumping
> > > > > up the request version. To add a required field, we will add it as
> a
> > > tagged
> > > > > field but force a version bump to all requests.
> > > > >
> > > > > The benefit of this approach is that (1) it's compatible with the
> > > format of
> > > > > the old request header; (2) it avoids duplicating new fields; and
> (3)
> > > there
> > > > > is no constraint on deprecating the old request header. It's
> slightly
> > > weird
> > > > > to bump up the version when adding a tagged field. But it still
> seems
> > > > > better than the alternatives.
> > > > >
> > > > > JR34. Since we now have different feature versions gating different
> > > RPCs,
> > > > > should we bump up GV, TV, etc., too?
> > > > >
> > > > > Jun
> > > > >
> > > > > On Thu, Jun 25, 2026 at 10:37 AM Andrew Schofield <
> > > schofielaj@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Hi Jun,
> > > > > > Thanks for the reply.
> > > > > >
> > > > > > JR27.1: What if we want to add non-optional fields to the request
> > > header
> > > > > > in the future? I think that such fields would be by definition
> future
> > > > > > fields which would not be understood by existing brokers. For
> > > serialization
> > > > > > reasons, I think we would use version 2+ tagged fields and the
> > > requirement
> > > > > > for non-optionality would be enforced by code, rather than by the
> > > protocol
> > > > > > schema. This avoids the field duplication.
> > > > > >
> > > > > > JR27.2: Yes, I don't like it, but when we inevitably do another
> > > KIP-896 to
> > > > > > remove support for ancient parts of the protocol, it's going to
> be
> > > another
> > > > > > KIP. That's all I meant.
> > > > > >
> > > > > > If I understand your proposal correctly compared with the
> existing
> > > KIP
> > > > > > text, it would look like this:
> > > > > > * Remove RequestHeader v3, and introduce ClientInstanceId as a
> tagged
> > > > > > field for versions 2+.
> > > > > > * Bump the request versions for all RPCs. We'd update the request
> > > JSON
> > > > > > schemas with something like "ClientInstanceIdVersions": "X+".
> This
> > > would
> > > > > > mean that the request would only be properly formed if it had the
> > > > > > ClientInstanceId present, and would also mean that ClientId
> could be
> > > null
> > > > > > for non-initial requests on each connection.
> > > > > > * We would create ApiVersions v6, simply as a matter of the
> bumping
> > > of
> > > > > > request versions for all RPCs, but its schema would be unchanged
> > > from v5.
> > > > > > * We would introduce OffsetDelete v1 as the first flexible
> version
> > > so that
> > > > > > it uses the v2 request header.
> > > > > > * We would update PushTelemetry and GetTelemetrySubscriptions as
> > > described
> > > > > > in the KIP and the ClientInstanceId would move to the request
> header.
> > > > > >
> > > > > > I think that works roughly the same as what we have today. I
> don't
> > > really
> > > > > > like the mandatory nature of the tagged field, but then I don't
> > > really like
> > > > > > the way that ApiVersions is pegged on a historical request header
> > > version.
> > > > > >
> > > > > > Do I have this correct? If so, I can update the KIP accordingly.
> > > > > >
> > > > > > Thanks,
> > > > > > Andrew
> > > > > >
> > > > > > On 2026/06/24 23:40:06 Jun Rao via dev wrote:
> > > > > > > Hi, Andrew,
> > > > > > >
> > > > > > > Thanks for the reply.
> > > > > > >
> > > > > > > JR27.1 What if we want to add non-optional fields to the
> request
> > > header
> > > > > > in
> > > > > > > the future? The choice I see is duplicating the field in the
> new
> > > request
> > > > > > > header and the new ApiVersion request. But it's not very clean.
> > > > > > > JR27.2 Requiring a major version API compatibility KIP is also
> a
> > > bit
> > > > > > > awkward.
> > > > > > >
> > > > > > > Here is yet another proposal. We add the ClientInstanceId to
> the
> > > request
> > > > > > > header as a tagged field and also bump up all request versions.
> > > This
> > > > > > avoids
> > > > > > > the header compatibility issue in SocketServer. The bumped-up
> > > version
> > > > > > > signals that the new field is actually required. On the server
> > > side, when
> > > > > > > receiving the new version of a request, we verify that the
> > > > > > ClientInstanceId
> > > > > > > field exists. If it's not present, we reject the request. This
> > > will be
> > > > > > the
> > > > > > > convention for adding future required fields to the header.
> > > Compared to
> > > > > > the
> > > > > > > current proposal, this avoids duplicating the field between
> request
> > > > > > header
> > > > > > > and ApiVersionRequest, and it provides a path for deprecating
> the
> > > older
> > > > > > > version of the request header. What do you think?
> > > > > > >
> > > > > > > Jun
> > > > > > >
> > > > > > > On Wed, Jun 24, 2026 at 2:15 AM Andrew Schofield <
> > > schofielaj@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi Jun,
> > > > > > > > Thanks for the reply.
> > > > > > > >
> > > > > > > > JR27: Yes, I enhanced that section of the KIP.
> > > > > > > > JR27.1: This KIP was unusual because we wanted to add a
> concept
> > > which
> > > > > > > > existed in the KIP-714 RPCs to the request header,
> complicating
> > > the
> > > > > > > > behavior of those RPCs, AND we wanted to change the handling
> of
> > > client
> > > > > > ID
> > > > > > > > without breaking older brokers. If we simply wanted to add a
> > > brand new
> > > > > > > > field to the request header, we can do it as a tagged field
> in
> > > request
> > > > > > > > header versions 2+.
> > > > > > > > JR27.2: Covered this too. We'd need a major version API
> > > compatibility
> > > > > > KIP.
> > > > > > > >
> > > > > > > > JR31: Yes. KIP updated.
> > > > > > > >
> > > > > > > > JR32: Yes. This is a minor inconvenience I feel. KIP updated.
> > > > > > > >
> > > > > > > > JR33: I don't see the value of a string comparison here.
> > > Personally,
> > > > > > I'm
> > > > > > > > happy with "assume".
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Andrew
> > > > > > > >
> > > > > > > > On 2026/06/23 22:52:15 Jun Rao via dev wrote:
> > > > > > > > > Hi, Andrew,
> > > > > > > > >
> > > > > > > > > Thanks for the reply.
> > > > > > > > >
> > > > > > > > > JR27. The code that changed the request header parsing was
> > > > > > introduced in
> > > > > > > > > 2019 (
> > > > > > > >
> > > > > >
> > >
> https://urldefense.com/v3/__https://github.com/apache/kafka/pull/7372__;!!Ayb5sqE7!scbWbTEEm2o-Y3MBGi829H2cpMWPRyrF9g2CW3lmRHyRmgBU2MyoRif2mFJpnfmvQ2x7fF4LrAJXdwH86ERR$
> > > > > > > > ). I agree that fixing it
> > > > > > > > > now is too late. We should document the path forward for
> > > ApiVersion.
> > > > > > > > Could
> > > > > > > > > we answer at least the following questions in the
> > > Compatibility,
> > > > > > > > > Deprecation, and Migration Plan section?
> > > > > > > > > JR27.1 What happens to ApiVersion if we change the request
> > > header in
> > > > > > the
> > > > > > > > > future?
> > > > > > > > > JR27.2 What happens if we ever want to deprecate v2 of the
> > > request
> > > > > > > > header?
> > > > > > > > >
> > > > > > > > > JR28. The new MV needs to be covered in the Compatibility,
> > > > > > Deprecation,
> > > > > > > > and
> > > > > > > > > Migration Plan section.
> > > > > > > > >
> > > > > > > > > JR31. "If a connection uses the v3 request header in its
> first
> > > > > > request,
> > > > > > > > it
> > > > > > > > > must specify a non-zero client instance ID and it must
> specify
> > > the
> > > > > > same
> > > > > > > > > client instance ID for all subsequent requests."
> > > > > > > > > Do we do the same if the first request is v6 of ApiVersion?
> > > > > > > > >
> > > > > > > > > JR32. "For subsequent requests using an earlier version of
> the
> > > > > > request
> > > > > > > > > header, the client sends the client ID". This means that
> > > subsequent
> > > > > > > > > ApiVersion V6 requests will carry the non-null clientID
> > > > > > unnecessarily.
> > > > > > > > >
> > > > > > > > > JR33. "After this KIP, the broker will assume that the
> client
> > > ID
> > > > > > from the
> > > > > > > > > initial request applies to all subsequent requests on a
> > > connection,
> > > > > > and
> > > > > > > > it
> > > > > > > > > will ignore the client ID specified on any subsequent
> > > requests."
> > > > > > > > > Should the broker verify that the clientId from subsequent
> > > request
> > > > > > match
> > > > > > > > > the first cached one, if not null?
> > > > > > > > >
> > > > > > > > >  Jun
> > > > > > > > >
> > > > > > > > > On Tue, Jun 23, 2026 at 6:05 AM Andrew Schofield <
> > > > > > schofielaj@apache.org>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi Jun,
> > > > > > > > > > Thanks for your reply.
> > > > > > > > > >
> > > > > > > > > > JR27: Unfortunately, I don't think this is acceptable. We
> > > would be
> > > > > > > > saying
> > > > > > > > > > that AK 4.5 clients can only connect to AK 4.5 or later
> > > brokers,
> > > > > > and
> > > > > > > > that
> > > > > > > > > > we'd create patch release for AK 4.0.x to AK 4.4.x. so
> AK 4.5
> > > > > > clients
> > > > > > > > could
> > > > > > > > > > connect to those too. We'd be preventing connection to
> AK 3.x
> > > > > > brokers
> > > > > > > > by AK
> > > > > > > > > > 4.5 clients. I don't see how we can break compatibility
> in a
> > > minor
> > > > > > > > release.
> > > > > > > > > > Here's the existing compatibility table:
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > >
> https://urldefense.com/v3/__https://kafka.apache.org/41/getting-started/compatibility/__;!!Ayb5sqE7!ppWU_jI9f7EY9DYwcbiOESSBG2TmPn9CHfLnVM5TaIMwWqHUbUbIiGre1GGKMr-HmelQlyP6ibUSyORCAgte$
> > > > > > > > > >
> > > > > > > > > > JR29: OK, makes sense to me.
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > Andrew
> > > > > > > > > >
> > > > > > > > > > On 2026/06/22 21:50:43 Jun Rao via dev wrote:
> > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > >
> > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > >
> > > > > > > > > > > JR27. I am not sure I like the approach of pinning the
> > > header to
> > > > > > v2
> > > > > > > > for
> > > > > > > > > > > ApiVersionsRequest. This means that in the future, each
> > > change
> > > > > > to the
> > > > > > > > > > > request header must be duplicated in the request
> itself.
> > > Here is
> > > > > > an
> > > > > > > > > > > alternative. Note that to detect an unsupported
> > > > > > ApiVersionRequest, we
> > > > > > > > > > don't
> > > > > > > > > > > need to parse the full v2 request header. Parsing the
> > > first two
> > > > > > > > fields
> > > > > > > > > > > ApiKey and ApiVersion is enough. So, we could patch all
> > > the 4.x
> > > > > > > > releases
> > > > > > > > > > > with a change that short-circuits parsing the full
> request
> > > header
> > > > > > > > based
> > > > > > > > > > on
> > > > > > > > > > > the first two fields. Then, we recommend upgrading
> from the
> > > > > > latest
> > > > > > > > 4.x
> > > > > > > > > > > releases to future releases. This way, we can still let
> > > > > > > > > > ApiVersionsRequest
> > > > > > > > > > > depend on the request header for current and future
> > > changes.
> > > > > > > > > > >
> > > > > > > > > > > JR29. The simplest thing is to upgrade the KRaft RPCs
> too
> > > to be
> > > > > > > > > > consistent.
> > > > > > > > > > >
> > > > > > > > > > > Jun
> > > > > > > > > > >
> > > > > > > > > > > On Sat, Jun 20, 2026 at 3:38 AM Andrew Schofield <
> > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > Thanks for these insightful comments. I did
> prototype the
> > > > > > earlier
> > > > > > > > v2
> > > > > > > > > > > > request header with tagged fields variant. I have now
> > > > > > prototyped
> > > > > > > > the v3
> > > > > > > > > > > > request header variant.
> > > > > > > > > > > >
> > > > > > > > > > > > JR27: You were of course entirely correct that a new
> > > version of
> > > > > > > > > > > > ApiVersions request cannot use a request header
> which is
> > > not
> > > > > > > > > > > > binary-compatible with what has gone before. As a
> > > result, I
> > > > > > have
> > > > > > > > > > introduced
> > > > > > > > > > > > a new version of ApiVersions request which includes
> > > > > > > > ClientInstanceId
> > > > > > > > > > in the
> > > > > > > > > > > > request body but continues to use the v2 request
> header.
> > > > > > > > > > > >
> > > > > > > > > > > > JR28: Yes, we need a new metadata version, which is
> > > > > > provisionally
> > > > > > > > > > > > IBP_4_5_IV0. I'll update the KIP with the final value
> > > when it
> > > > > > is
> > > > > > > > > > assigned.
> > > > > > > > > > > >
> > > > > > > > > > > > JR29: I don't have any strong feelings on this. I
> > > suppose for
> > > > > > each
> > > > > > > > > > inter
> > > > > > > > > > > > broker RPC version that is bumped, we need to
> introduce
> > > an MV
> > > > > > > > check. We
> > > > > > > > > > > > cannot avoid this for RPCs which are also used by
> > > clients such
> > > > > > as
> > > > > > > > > > Fetch.
> > > > > > > > > > > > For purely inter-broker RPCs, we could just exempt
> them
> > > from
> > > > > > the
> > > > > > > > > > version
> > > > > > > > > > > > bump. What do you recommend here?
> > > > > > > > > > > >
> > > > > > > > > > > > JR30: Done. INVALID_REQUEST. I did consider
> permitting
> > > zero
> > > > > > client
> > > > > > > > > > > > instance ID for inter-broker connections, but I
> decided
> > > that I
> > > > > > > > > > preferred
> > > > > > > > > > > > not creating another rule.
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks,
> > > > > > > > > > > > Andrew
> > > > > > > > > > > >
> > > > > > > > > > > > On 2026/06/17 22:45:07 Andrew Schofield wrote:
> > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > >
> > > > > > > > > > > > > JR27: I am familiar with KIP-511 and the oddness of
> > > > > > ApiVersions.
> > > > > > > > You
> > > > > > > > > > > > make an excellent point. I suspect that
> > > ApiVersionsRequest will
> > > > > > > > have
> > > > > > > > > > to be
> > > > > > > > > > > > limited to the v2 request header, just as it is
> > > restricted to
> > > > > > the
> > > > > > > > v0
> > > > > > > > > > > > response header.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'll do some experimentation.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > Andrew
> > > > > > > > > > > > >
> > > > > > > > > > > > > On 2026/06/17 17:35:17 Jun Rao via dev wrote:
> > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Thanks for the reply. A few more comments.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > JR27. It seems that we have a compatibility issue
> > > with
> > > > > > > > > > > > ApiVersionRequest v6
> > > > > > > > > > > > > > depending on RequestHeader v3. This happens when
> a
> > > new
> > > > > > client
> > > > > > > > > > issues
> > > > > > > > > > > > > > ApiVersionRequest v6 to an old broker (one that
> only
> > > > > > supports
> > > > > > > > > > > > > > ApiVersionRequest v5). The SocketServer in the
> > > broker will
> > > > > > > > first
> > > > > > > > > > try to
> > > > > > > > > > > > > > read the request header. It tries to find the
> header
> > > > > > version
> > > > > > > > from
> > > > > > > > > > the
> > > > > > > > > > > > > > request version. Since the broker doesn't know
> > > > > > > > ApiVersionRequest
> > > > > > > > > > v6, it
> > > > > > > > > > > > > > uses v2 to parse the request header.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The v2's wire format for the request header is:
> > > ApiKey |
> > > > > > > > > > ApiVersion |
> > > > > > > > > > > > > > CorrelationId | ClientId | tagged-fields-varint
> > > > > > > > > > > > > > The v3's wire format for the request header is:
> > > ApiKey |
> > > > > > > > > > ApiVersion |
> > > > > > > > > > > > > > CorrelationId | ClientId | ClientInstanceId(16
> > > bytes) |
> > > > > > > > > > tagged-fields
> > > > > > > > > > > > varint
> > > > > > > > > > > > > > The first 4 fields are identical, allowing the
> > > broker to
> > > > > > parse
> > > > > > > > > > them.
> > > > > > > > > > > > The
> > > > > > > > > > > > > > broker then tries to read the
> tagged-fields-varint
> > > using
> > > > > > the
> > > > > > > > > > serialized
> > > > > > > > > > > > > > bytes intended for ClientInstanceId. This could
> lead
> > > to a
> > > > > > > > parsing
> > > > > > > > > > > > error and
> > > > > > > > > > > > > > raise an invalid request error. The broker will
> > > close the
> > > > > > > > > > connection
> > > > > > > > > > > > > > instead of sending a v0 response for
> > > ApiVersionRequest.
> > > > > > Then
> > > > > > > > the
> > > > > > > > > > client
> > > > > > > > > > > > > > will never be able to detect supported API
> versions
> > > on the
> > > > > > old
> > > > > > > > > > broker.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The same problem didn't exist when
> ApiVersionRequest
> > > > > > changed
> > > > > > > > from
> > > > > > > > > > the
> > > > > > > > > > > > v1
> > > > > > > > > > > > > > request header to v2 because the wire format for
> v1
> > > is a
> > > > > > > > prefix of
> > > > > > > > > > v2.
> > > > > > > > > > > > This
> > > > > > > > > > > > > > problem exists for this KIP because the wire
> format
> > > of v2
> > > > > > is no
> > > > > > > > > > longer
> > > > > > > > > > > > a
> > > > > > > > > > > > > > prefix of v3.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > JR28. Since we are bumping up the version of
> inter
> > > broker
> > > > > > > > > > requests, we
> > > > > > > > > > > > need
> > > > > > > > > > > > > > to gate them by introducing a new MV.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > JR29. Could you specify whether the version for
> > > KRaft PRCs
> > > > > > > > will be
> > > > > > > > > > > > bumped
> > > > > > > > > > > > > > too?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > JR30. "If a connection uses the v3 request
> header in
> > > its
> > > > > > first
> > > > > > > > > > > > request, it
> > > > > > > > > > > > > > must specify a non-zero client instance ID"
> > > > > > > > > > > > > > Could we define the broker's behavior when a v3
> > > request
> > > > > > header
> > > > > > > > > > > > contains a 0
> > > > > > > > > > > > > > client instance ID?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Tue, Jun 16, 2026 at 1:25 AM Andrew Schofield
> <
> > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR26: Yes, I was considering open-ended version
> > > ranges.
> > > > > > I've
> > > > > > > > > > updated
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > KIP.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Now that we have a new request header version,
> I
> > > think
> > > > > > it's
> > > > > > > > safe
> > > > > > > > > > to
> > > > > > > > > > > > > > > reintroduce the client ID optimisation. I've
> added
> > > that
> > > > > > into
> > > > > > > > the
> > > > > > > > > > KIP
> > > > > > > > > > > > also.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Let me know what you think.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On 2026/06/15 17:46:00 Jun Rao via dev wrote:
> > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Thanks for the reply. Just a minor comment.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > JR26. "The keys of the map are either single
> > > versions
> > > > > > like
> > > > > > > > "0"
> > > > > > > > > > or
> > > > > > > > > > > > closed
> > > > > > > > > > > > > > > > version ranges like "1-2"."
> > > > > > > > > > > > > > > > It will be useful to support open-ended
> > > versions. That
> > > > > > way,
> > > > > > > > > > "3":
> > > > > > > > > > > > "3"
> > > > > > > > > > > > > > > could
> > > > > > > > > > > > > > > > be "3+": "3". This part won't need to change
> in
> > > the
> > > > > > future
> > > > > > > > > > when we
> > > > > > > > > > > > bump
> > > > > > > > > > > > > > > up
> > > > > > > > > > > > > > > > the request version without changing the
> header.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Fri, Jun 12, 2026 at 2:12 PM Andrew
> Schofield
> > > <
> > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > JR25: I agree. I've changed to a
> > > headerVersions map
> > > > > > in
> > > > > > > > both
> > > > > > > > > > the
> > > > > > > > > > > > request
> > > > > > > > > > > > > > > > > and response schemas.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Let me know what you think.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On 2026/06/12 03:39:39 Jun Rao via dev
> wrote:
> > > > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Thanks for the updated KIP.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > JR25. I have some concerns about adding
> the
> > > > > > > > > > > > clientInstanceIdVersions
> > > > > > > > > > > > > > > > > field
> > > > > > > > > > > > > > > > > > to the schema. First of all, it only
> applies
> > > to
> > > > > > > > requests,
> > > > > > > > > > but
> > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > > responses. So, it's a bit weird to add
> it to
> > > the
> > > > > > > > general
> > > > > > > > > > > > schema.
> > > > > > > > > > > > > > > > > Secondly,
> > > > > > > > > > > > > > > > > > it's very specific to the new field
> added to
> > > the
> > > > > > > > request
> > > > > > > > > > > > header. If
> > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > change the request header again in the
> > > future, we
> > > > > > need
> > > > > > > > > > another
> > > > > > > > > > > > way
> > > > > > > > > > > > > > > to map
> > > > > > > > > > > > > > > > > > request versions to the new header
> version.
> > > > > > Ideally, we
> > > > > > > > > > should
> > > > > > > > > > > > have a
> > > > > > > > > > > > > > > > > > generic way to map request versions to
> all
> > > future
> > > > > > > > header
> > > > > > > > > > > > versions.
> > > > > > > > > > > > > > > One
> > > > > > > > > > > > > > > > > > possibility is to introduce a
> headerVersion
> > > field
> > > > > > in
> > > > > > > > the
> > > > > > > > > > > > schema.
> > > > > > > > > > > > > > > Then,
> > > > > > > > > > > > > > > > > each
> > > > > > > > > > > > > > > > > > request/response can use this field to
> map
> > > its
> > > > > > > > versions to
> > > > > > > > > > the
> > > > > > > > > > > > header
> > > > > > > > > > > > > > > > > > versions.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Tue, Jun 9, 2026 at 4:55 AM Andrew
> > > Schofield <
> > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Hi Matthias,
> > > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I have change the version property for
> > > > > > introducing
> > > > > > > > client
> > > > > > > > > > > > instance
> > > > > > > > > > > > > > > ID
> > > > > > > > > > > > > > > > > into
> > > > > > > > > > > > > > > > > > > the request headers to be
> > > > > > `clientInstanceIdVersions`
> > > > > > > > > > which
> > > > > > > > > > > > is now
> > > > > > > > > > > > > > > an
> > > > > > > > > > > > > > > > > > > open-ended range, such as "3+", more
> > > closely
> > > > > > matching
> > > > > > > > > > what
> > > > > > > > > > > > we have
> > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > flexible versions.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I also added a change to the
> > > > > > > > > > > > RebalanceConsumer.clientInstanceId
> > > > > > > > > > > > > > > method
> > > > > > > > > > > > > > > > > > > introduced in KIP-1306.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On 2026/06/03 18:31:06 "Matthias J.
> Sax"
> > > wrote:
> > > > > > > > > > > > > > > > > > > > Thanks Andrew.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >  From a KIP-714 perspective, this is
> a
> > > great
> > > > > > > > change,
> > > > > > > > > > as it
> > > > > > > > > > > > make
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > new
> > > > > > > > > > > > > > > > > > > > RPCs and client/broker cross-version
> > > > > > compatibility
> > > > > > > > > > clean.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > One question about your
> `DeleteGroups`
> > > RPC
> > > > > > example.
> > > > > > > > > > Should
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > new
> > > > > > > > > > > > > > > > > > > > version of the RPC say
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > "clientInstanceIdVersion": "3+",
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > ie, 3+ instead of 3? Similar for
> other
> > > request,
> > > > > > > > which
> > > > > > > > > > > > don't use
> > > > > > > > > > > > > > > `+`
> > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > `clientInstanceIdVersion` field.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > -Matthias
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On 6/2/26 7:42 AM, Andrew Schofield
> > > wrote:
> > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > Following on from the discussion
> in the
> > > > > > > > community,
> > > > > > > > > > and
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > difficulty
> > > > > > > > > > > > > > > > > > > of trying to accommodate the client
> > > instance ID
> > > > > > in a
> > > > > > > > > > tagged
> > > > > > > > > > > > field
> > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > > acceptable complexity, I have made a
> > > significant
> > > > > > > > change
> > > > > > > > > > to
> > > > > > > > > > > > the KIP.
> > > > > > > > > > > > > > > > > Now, it
> > > > > > > > > > > > > > > > > > > introduces v3 of the request header
> > > containing
> > > > > > the
> > > > > > > > client
> > > > > > > > > > > > instance
> > > > > > > > > > > > > > > ID
> > > > > > > > > > > > > > > > > as a
> > > > > > > > > > > > > > > > > > > proper field.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/KAFKA/KIP-1313*3A*Client*instance*ID*in*all*request*headers__;JSsrKysrKys!!Ayb5sqE7!pUZS25PuTKdhiqvTGcwDKbclqpG8dFOzw2Ax9WxVM6Sb09PVQ0gl1i0gjlr2_Krr66agbuVC2qLGgUcg7vrW$
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Please review and let me know what
> you
> > > think.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On 2026/05/28 21:51:01 "Matthias J.
> > > Sax"
> > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > >> Thanks Andrew. I agree to the
> issue
> > > that
> > > > > > tagged
> > > > > > > > > > fields
> > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > optional.
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > >> Nevertheless, I find the proposed
> > > > > > compatibility
> > > > > > > > > > > > protocol too
> > > > > > > > > > > > > > > > > complex
> > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > >> unnecessary, and would still
> prefer a
> > > > > > version
> > > > > > > > bump
> > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > >>
> > > `GetTelemetrySubscriptionsRequest/Reponse`
> > > > > > to
> > > > > > > > clean
> > > > > > > > > > it
> > > > > > > > > > > > all
> > > > > > > > > > > > > > > up. --
> > > > > > > > > > > > > > > > > For
> > > > > > > > > > > > > > > > > > > > >> `PushTelemetryRequest` the
> argument
> > > from
> > > > > > above
> > > > > > > > > > applies,
> > > > > > > > > > > > so
> > > > > > > > > > > > > > > > > leaving it
> > > > > > > > > > > > > > > > > > > > >> untouched is ok.
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > >> I don't see why
> > > > > > > > `GetTelemetrySubscriptionsRequest`
> > > > > > > > > > > > would need
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > encode
> > > > > > > > > > > > > > > > > > > > >> the `clientInstandId` in it's
> request
> > > body.
> > > > > > > > Given
> > > > > > > > > > that
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > >> `clientInstanceId` is a random
> UUID,
> > > the
> > > > > > > > returned
> > > > > > > > > > > > subscription
> > > > > > > > > > > > > > > > > cannot
> > > > > > > > > > > > > > > > > > > > >> really depend on it. So why would
> we
> > > need to
> > > > > > > > send
> > > > > > > > > > it to
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > broker?
> > > > > > > > > > > > > > > > > > > > >> Right now, it's set to ZERO only
> for
> > > the
> > > > > > > > purpose to
> > > > > > > > > > get
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > broker to
> > > > > > > > > > > > > > > > > > > > >> assign a new UUID. But it has
> nothing
> > > to do
> > > > > > > > with the
> > > > > > > > > > > > actual
> > > > > > > > > > > > > > > "what
> > > > > > > > > > > > > > > > > > > > >> metrics should I send" question.
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > >> To be fair, KIP-714 lists
> > > > > > `client_instance_id`
> > > > > > > > as a
> > > > > > > > > > > > field that
> > > > > > > > > > > > > > > > > can be
> > > > > > > > > > > > > > > > > > > > >> used to define a subscription.
> But it
> > > seems
> > > > > > > > rather
> > > > > > > > > > > > useless in
> > > > > > > > > > > > > > > > > practice
> > > > > > > > > > > > > > > > > > > > >> to me? I a user defines a
> > > subscription, they
> > > > > > > > cannot
> > > > > > > > > > > > know the
> > > > > > > > > > > > > > > UUID.
> > > > > > > > > > > > > > > > > > > Thus,
> > > > > > > > > > > > > > > > > > > > >> I think we should actually drop
> > > supporting
> > > > > > > > > > > > > > > `client_instance_id`
> > > > > > > > > > > > > > > > > as a
> > > > > > > > > > > > > > > > > > > > >> "subscription matching
> parameter"? Of
> > > > > > course,
> > > > > > > > there
> > > > > > > > > > is a
> > > > > > > > > > > > > > > backward
> > > > > > > > > > > > > > > > > > > > >> compatibility question, but I
> think
> > > we can
> > > > > > > > address
> > > > > > > > > > > > this: if
> > > > > > > > > > > > > > > > > brokers
> > > > > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > > >> upgraded and they have an existing
> > > > > > > > > > `client_instance_id`
> > > > > > > > > > > > based
> > > > > > > > > > > > > > > > > > > > >> subscription defined, they could
> > > advertise
> > > > > > to
> > > > > > > > only
> > > > > > > > > > > > support
> > > > > > > > > > > > > > > v0, and
> > > > > > > > > > > > > > > > > > > they
> > > > > > > > > > > > > > > > > > > > >> should log a warning that this
> > > feature is
> > > > > > > > > > deprecated.
> > > > > > > > > > > > New
> > > > > > > > > > > > > > > brokers
> > > > > > > > > > > > > > > > > > > would
> > > > > > > > > > > > > > > > > > > > >> also not allow to use
> > > `client_instance_id`
> > > > > > any
> > > > > > > > > > longer to
> > > > > > > > > > > > > > > define a
> > > > > > > > > > > > > > > > > > > > >> subscription.
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > >> Similarly, for
> > > > > > > > `GetTelemetrySubscriptionsResponse`,
> > > > > > > > > > we
> > > > > > > > > > > > only
> > > > > > > > > > > > > > > need
> > > > > > > > > > > > > > > > > > > > >> `clientInstanceId` if the broker
> > > computes
> > > > > > the
> > > > > > > > UUID.
> > > > > > > > > > But
> > > > > > > > > > > > if we
> > > > > > > > > > > > > > > let
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > >> client compute it, this field is
> not
> > > needed
> > > > > > any
> > > > > > > > > > longer.
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > >> -Matthias
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > >> On 5/28/26 1:21 AM, Andrew
> Schofield
> > > wrote:
> > > > > > > > > > > > > > > > > > > > >>> Hi Jun,
> > > > > > > > > > > > > > > > > > > > >>> Thanks for your response.
> > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > >>> JR24: I'll update the KIP
> shortly.
> > > Here's a
> > > > > > > > > > summary.
> > > > > > > > > > > > The
> > > > > > > > > > > > > > > various
> > > > > > > > > > > > > > > > > > > modern group protocol heartbeat
> requests
> > > encode
> > > > > > the
> > > > > > > > > > member
> > > > > > > > > > > > ID as a
> > > > > > > > > > > > > > > > > string
> > > > > > > > > > > > > > > > > > > for historical reasons, even though
> it's in
> > > > > > practice
> > > > > > > > a
> > > > > > > > > > UUID.
> > > > > > > > > > > > The
> > > > > > > > > > > > > > > Apache
> > > > > > > > > > > > > > > > > > > Kafka Java client happens to use
> > > > > > > > > > > > org.apache.kafka.common.Uuid to
> > > > > > > > > > > > > > > > > create the
> > > > > > > > > > > > > > > > > > > member ID and convert it into a string.
> > > This
> > > > > > means
> > > > > > > > that
> > > > > > > > > > when
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > clientInstanceId is converted into a
> > > string, its
> > > > > > > > encoding
> > > > > > > > > > > > matches
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > member ID and it all lines up. However,
> > > there are
> > > > > > > > other
> > > > > > > > > > ways
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > encode
> > > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > > UUID into a string and I know for a
> fact
> > > that the
> > > > > > > > > > librdkafka
> > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > does it
> > > > > > > > > > > > > > > > > > > differently.
> > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > >>> Thanks,
> > > > > > > > > > > > > > > > > > > > >>> Andrew
> > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > >>> On 2026/05/27 17:11:25 Jun Rao
> via
> > > dev
> > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > >>>> Hi, Andrew,
> > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > >>>> Thanks for the reply. One more
> > > comment.
> > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > >>>> JR24. "The alignment of other
> > > identifiers
> > > > > > is
> > > > > > > > by
> > > > > > > > > > > > convention
> > > > > > > > > > > > > > > (and
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > Java
> > > > > > > > > > > > > > > > > > > > >>>> client will follow the
> convention)
> > > rather
> > > > > > than
> > > > > > > > > > > > mandate."
> > > > > > > > > > > > > > > Could
> > > > > > > > > > > > > > > > > you
> > > > > > > > > > > > > > > > > > > describe
> > > > > > > > > > > > > > > > > > > > >>>> the convention to convert a
> > > > > > clientInstanceId
> > > > > > > > > > (UUID)
> > > > > > > > > > > > to a
> > > > > > > > > > > > > > > > > memberId
> > > > > > > > > > > > > > > > > > > (String)?
> > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > >>>> Jun
> > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > >>>> On Tue, May 19, 2026 at 2:36 AM
> > > Andrew
> > > > > > > > Schofield <
> > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > >>>>> 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 <
> > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > >>>>>> 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 <
> > > > > > > > > > > > > > > > > > > > >>>>>>> schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > >>>>>>>>> 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 <
> > > > > > > > > > > > > > > > > > > > >>>>>>> schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> 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
> > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] KIP-1313: Client instance ID in all request headers

[Andrew Schofield <an...@outlook.com>]

Hi Luke,
Thanks for the reply.

LC1: Yes, it applies to those connections too.

Thanks,
Andrew

________________________________________
From: Luke Chen <sh...@gmail.com>
Sent: 19 August 2026 11:59
To: dev@kafka.apache.org <de...@kafka.apache.org>
Cc: Jun Rao <ju...@confluent.io>
Subject: Re: [DISCUSS] KIP-1313: Client instance ID in all request headers

Hi Andrew,

Thanks for the KIP.

LC1. It looks like in the KIP, we always assume the client firstly connects
to broker node. So what about the admin client directly queries the
controller node via "bootstrap.controller" option? Does this KIP also apply
to this client -> controller connections? I think so, right?


Thanks,
Luke

On Fri, Aug 7, 2026 at 1:20 AM Jun Rao via dev <de...@kafka.apache.org> wrote:

> Hi, Andrew,
>
> Thanks for the reply.
>
> JR39. There is still some inconsistency.
> For clientInstanceID, we reject any subsequent requests which specify a
> different value for the client instance ID. But for clientID, we reject
> subsequent requests if the client ID is specified (request header v3 or
> later).
>
> Jun
>
>
> On Thu, Aug 6, 2026 at 12:47 AM Andrew Schofield <sc...@apache.org>
> wrote:
>
> > Hi Jun,
> > Thanks for your reply.
> >
> > JR39: KIP description tightened up. That should do the trick.
> >
> > Thanks,
> > Andrew
> >
> > On 2026/08/05 17:28:34 Jun Rao via dev wrote:
> > > Hi, Andrew,
> > >
> > > Thanks for the reply.
> > >
> > > JR39. For clientInstanceID, we have: "If a client specifies a reserved
> > > client instance ID (zero or one), the request will be rejected with
> error
> > > code INVALID_REQUEST ."
> > > For clientId, we have: "After this KIP, the broker will assume that the
> > > client ID from the initial request applies to all subsequent requests
> > > on a connection,
> > > and it will ignore the client ID specified on any subsequent requests."
> > > Could we make the behavior consistent between these two?
> > >
> > > Jun
> > >
> > >
> > > On Tue, Aug 4, 2026 at 1:05 PM Andrew Schofield <schofielaj@apache.org
> >
> > > wrote:
> > >
> > > > Hi Jun,
> > > > Thanks for the reply.
> > > >
> > > > JR37: It had escaped me that ClientInstanceId is a tagged field, so
> > you're
> > > > absolutely right. (I am not an AI.) I'll update the KIP.
> > > >
> > > > Thanks,
> > > > Andrew
> > > >
> > > > On 2026/08/04 18:24:19 Jun Rao via dev wrote:
> > > > > Hi, Andrew,
> > > > >
> > > > > Thanks for the reply.
> > > > >
> > > > > JR37. UUID is 16 bytes. If it's omitted in subsequent requests, we
> > save
> > > > 16
> > > > > bytes, right?
> > > > >
> > > > > Jun
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Aug 4, 2026 at 5:47 AM Andrew Schofield <
> > schofielaj@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Hi Jun,
> > > > > > Thanks for your reply.
> > > > > >
> > > > > > JR37: Unlike with clientId where space is saved by not
> > transmitting it
> > > > on
> > > > > > every request, there's nothing to be gained by omitting
> > > > clientInstanceId on
> > > > > > later requests. I prefer to leave it as is.
> > > > > >
> > > > > > JR38: OK, I've updated those paragraphs in the KIP to exclude the
> > > > reserved
> > > > > > UUIDs.
> > > > > >
> > > > > > Thanks,
> > > > > > Andrew
> > > > > >
> > > > > > On 2026/08/03 20:23:39 Jun Rao via dev wrote:
> > > > > > > Hi, Andrew,
> > > > > > >
> > > > > > > Thanks for the reply.
> > > > > > >
> > > > > > > JR37. Will it be better to require ClientInstanceId only on the
> > first
> > > > > > > request, to be consistent with clientId?
> > > > > > >
> > > > > > > JR38. "must specify a non-zero client instance ID". one_uuid is
> > also
> > > > a
> > > > > > > reserved one in the Uuid class. Should we exclude that one too?
> > > > > > >
> > > > > > > Jun
> > > > > > >
> > > > > > > On Fri, Jul 31, 2026 at 9:10 AM Andrew Schofield <
> > > > schofielaj@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi Jun,
> > > > > > > > Thanks for the reply and sorry for the delay. Lots of 4.4
> stuff
> > > > got in
> > > > > > the
> > > > > > > > way.
> > > > > > > >
> > > > > > > > JR34: EligibleLeaderReplicasVersion and KRaftVersion also use
> > > > > > ApiVersion
> > > > > > > > to negotiate the RPC versions. I do not believe we need to
> > bump up
> > > > > > other
> > > > > > > > feature versions as a result of the RPC version bumps in this
> > KIP.
> > > > > > > >
> > > > > > > > JR35: Yes, good catch. In order to handle client ID-based
> > quotas
> > > > for
> > > > > > > > forwarded requests, it will be necessary to populate the
> > client ID
> > > > in
> > > > > > the
> > > > > > > > forwarded request header. KIP updated.
> > > > > > > >
> > > > > > > > JR36: I hadn't considered MV to be a feature version, but I
> > > > understand.
> > > > > > > > KIP updated.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Andrew
> > > > > > > >
> > > > > > > > On 2026/06/29 16:23:09 Jun Rao via dev wrote:
> > > > > > > > > Hi, Andrew,
> > > > > > > > >
> > > > > > > > > Thanks for the reply.
> > > > > > > > >
> > > > > > > > > JR34. Transaction coordinator uses ApiVersion to negotiate
> > the
> > > > PRC
> > > > > > > > > versions. Therefore, if there is no functional change,
> there
> > is
> > > > no
> > > > > > need
> > > > > > > > to
> > > > > > > > > bump the TV version. I am not sure about
> > > > > > EligibleLeaderReplicasVersion
> > > > > > > > > and KRaftVersion.
> > > > > > > > > It would be useful to have the experts chime in.
> > > > > > > > >
> > > > > > > > > JR35. Envelope/forwarding interaction: When a broker
> > forwards a
> > > > > > client
> > > > > > > > > request to the controller via EnvelopeUtils
> > > > > > > > (parseForwardedRequestHeader),
> > > > > > > > > the inner header may have its clientId optimized to null.
> > Some
> > > > quota
> > > > > > > > > enforcement (e.g. controller mutation) may depend on the
> > non-null
> > > > > > > > clientId.
> > > > > > > > > The per-connection caching occurs on the original
> > client↔broker
> > > > > > > > connection, not
> > > > > > > > > the broker↔controller one. Should the forwarded request
> > preserve
> > > > the
> > > > > > > > > non-null resolved (cached) client.id?
> > > > > > > > >
> > > > > > > > > JR36. "This KIP does not need to introduce any feature
> > version
> > > > > > bumps."
> > > > > > > > This
> > > > > > > > > is not very accurate since MV is a feature version and is
> > bumped.
> > > > > > > > >
> > > > > > > > > Jun
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Fri, Jun 26, 2026 at 12:42 AM Andrew Schofield <
> > > > > > schofielaj@apache.org
> > > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi Jun,
> > > > > > > > > > I've updated the KIP.
> > > > > > > > > >
> > > > > > > > > > JS34: I don't believe that we need to introduce any new
> > feature
> > > > > > > > versions
> > > > > > > > > > for this KIP. For example, we do not need a new
> > ShareVersion
> > > > since
> > > > > > that
> > > > > > > > > > enabled share groups (SV_1) and controls the versioning
> of
> > the
> > > > > > records
> > > > > > > > on
> > > > > > > > > > the internal topics (SV_2). I think the same applies for
> > the
> > > > > > others. I
> > > > > > > > > > understand GroupVersion and StreamsVersion, and I think
> > they
> > > > > > follow the
> > > > > > > > > > same reasoning as ShareVersion. I don't know
> > > > TransactionVersion or
> > > > > > > > > > EligibleLeaderReplicasVersion, so let me know whether
> > those are
> > > > > > > > different
> > > > > > > > > > in this regard.
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > Andrew
> > > > > > > > > >
> > > > > > > > > > On 2026/06/25 21:32:27 Andrew Schofield wrote:
> > > > > > > > > > > Hi Jun,
> > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > >
> > > > > > > > > > > JR27: Yes, makes sense. So request header v3 is
> > > > binary-compatible
> > > > > > > > with
> > > > > > > > > > request header v2.
> > > > > > > > > > >
> > > > > > > > > > > JS34: Yes, I think so.
> > > > > > > > > > >
> > > > > > > > > > > I'll update the KIP tomorrow morning.
> > > > > > > > > > >
> > > > > > > > > > > Thanks,
> > > > > > > > > > > Andrew
> > > > > > > > > > >
> > > > > > > > > > > On 2026/06/25 20:23:57 Jun Rao via dev wrote:
> > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > >
> > > > > > > > > > > > JR27. I was thinking of the following, which is
> > slightly
> > > > > > different
> > > > > > > > from
> > > > > > > > > > > > what you described.
> > > > > > > > > > > > * Bump RequestHeader to v3, and introduce
> > ClientInstanceId
> > > > as a
> > > > > > > > tagged
> > > > > > > > > > > > field for versions 3+ and change the semantic of the
> > > > existing
> > > > > > field
> > > > > > > > > > > > clientId (only need to be populated by the first
> > request).
> > > > > > > > > > > > * Bump the request versions for all RPCs including
> > > > ApiVersion
> > > > > > and
> > > > > > > > map
> > > > > > > > > > to
> > > > > > > > > > > > the new version to use v3 of RequestHeader.
> > > > > > > > > > > > * On the server side, when a new request version is
> > seen,
> > > > we
> > > > > > > > enforce
> > > > > > > > > > the
> > > > > > > > > > > > presence of ClientInstanceId and reject the request
> if
> > it
> > > > is
> > > > > > > > missing.
> > > > > > > > > > > > Essentially, treat it as a required field. We also
> > cache
> > > > the
> > > > > > > > clientId
> > > > > > > > > > from
> > > > > > > > > > > > the first request and ignore it from subsequent ones.
> > > > > > > > > > > > * We would introduce OffsetDelete v1 as the first
> > flexible
> > > > > > version
> > > > > > > > so
> > > > > > > > > > that
> > > > > > > > > > > > it uses the v3 request header.
> > > > > > > > > > > > * We would update PushTelemetry and
> > > > GetTelemetrySubscriptions
> > > > > > as
> > > > > > > > > > described
> > > > > > > > > > > > in the KIP and the ClientInstanceId would move to the
> > > > request
> > > > > > > > header.
> > > > > > > > > > > >
> > > > > > > > > > > > In the future, if we want to add a new truly optional
> > > > field to
> > > > > > > > > > > > RequestHeader, we can continue adding it as a tagged
> > field
> > > > > > without
> > > > > > > > > > bumping
> > > > > > > > > > > > up the request version. To add a required field, we
> > will
> > > > add
> > > > > > it as
> > > > > > > > a
> > > > > > > > > > tagged
> > > > > > > > > > > > field but force a version bump to all requests.
> > > > > > > > > > > >
> > > > > > > > > > > > The benefit of this approach is that (1) it's
> > compatible
> > > > with
> > > > > > the
> > > > > > > > > > format of
> > > > > > > > > > > > the old request header; (2) it avoids duplicating new
> > > > fields;
> > > > > > and
> > > > > > > > (3)
> > > > > > > > > > there
> > > > > > > > > > > > is no constraint on deprecating the old request
> header.
> > > > It's
> > > > > > > > slightly
> > > > > > > > > > weird
> > > > > > > > > > > > to bump up the version when adding a tagged field.
> But
> > it
> > > > still
> > > > > > > > seems
> > > > > > > > > > > > better than the alternatives.
> > > > > > > > > > > >
> > > > > > > > > > > > JR34. Since we now have different feature versions
> > gating
> > > > > > different
> > > > > > > > > > RPCs,
> > > > > > > > > > > > should we bump up GV, TV, etc., too?
> > > > > > > > > > > >
> > > > > > > > > > > > Jun
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Jun 25, 2026 at 10:37 AM Andrew Schofield <
> > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > > >
> > > > > > > > > > > > > JR27.1: What if we want to add non-optional fields
> > to the
> > > > > > request
> > > > > > > > > > header
> > > > > > > > > > > > > in the future? I think that such fields would be by
> > > > > > definition
> > > > > > > > future
> > > > > > > > > > > > > fields which would not be understood by existing
> > > > brokers. For
> > > > > > > > > > serialization
> > > > > > > > > > > > > reasons, I think we would use version 2+ tagged
> > fields
> > > > and
> > > > > > the
> > > > > > > > > > requirement
> > > > > > > > > > > > > for non-optionality would be enforced by code,
> rather
> > > > than
> > > > > > by the
> > > > > > > > > > protocol
> > > > > > > > > > > > > schema. This avoids the field duplication.
> > > > > > > > > > > > >
> > > > > > > > > > > > > JR27.2: Yes, I don't like it, but when we
> inevitably
> > do
> > > > > > another
> > > > > > > > > > KIP-896 to
> > > > > > > > > > > > > remove support for ancient parts of the protocol,
> > it's
> > > > going
> > > > > > to
> > > > > > > > be
> > > > > > > > > > another
> > > > > > > > > > > > > KIP. That's all I meant.
> > > > > > > > > > > > >
> > > > > > > > > > > > > If I understand your proposal correctly compared
> > with the
> > > > > > > > existing
> > > > > > > > > > KIP
> > > > > > > > > > > > > text, it would look like this:
> > > > > > > > > > > > > * Remove RequestHeader v3, and introduce
> > > > ClientInstanceId as
> > > > > > a
> > > > > > > > tagged
> > > > > > > > > > > > > field for versions 2+.
> > > > > > > > > > > > > * Bump the request versions for all RPCs. We'd
> > update the
> > > > > > request
> > > > > > > > > > JSON
> > > > > > > > > > > > > schemas with something like
> > "ClientInstanceIdVersions":
> > > > "X+".
> > > > > > > > This
> > > > > > > > > > would
> > > > > > > > > > > > > mean that the request would only be properly formed
> > if it
> > > > > > had the
> > > > > > > > > > > > > ClientInstanceId present, and would also mean that
> > > > ClientId
> > > > > > > > could be
> > > > > > > > > > null
> > > > > > > > > > > > > for non-initial requests on each connection.
> > > > > > > > > > > > > * We would create ApiVersions v6, simply as a
> matter
> > of
> > > > the
> > > > > > > > bumping
> > > > > > > > > > of
> > > > > > > > > > > > > request versions for all RPCs, but its schema would
> > be
> > > > > > unchanged
> > > > > > > > > > from v5.
> > > > > > > > > > > > > * We would introduce OffsetDelete v1 as the first
> > > > flexible
> > > > > > > > version
> > > > > > > > > > so that
> > > > > > > > > > > > > it uses the v2 request header.
> > > > > > > > > > > > > * We would update PushTelemetry and
> > > > > > GetTelemetrySubscriptions as
> > > > > > > > > > described
> > > > > > > > > > > > > in the KIP and the ClientInstanceId would move to
> the
> > > > request
> > > > > > > > header.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I think that works roughly the same as what we have
> > > > today. I
> > > > > > > > don't
> > > > > > > > > > really
> > > > > > > > > > > > > like the mandatory nature of the tagged field, but
> > then I
> > > > > > don't
> > > > > > > > > > really like
> > > > > > > > > > > > > the way that ApiVersions is pegged on a historical
> > > > request
> > > > > > header
> > > > > > > > > > version.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Do I have this correct? If so, I can update the KIP
> > > > > > accordingly.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > Andrew
> > > > > > > > > > > > >
> > > > > > > > > > > > > On 2026/06/24 23:40:06 Jun Rao via dev wrote:
> > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > JR27.1 What if we want to add non-optional fields
> > to
> > > > the
> > > > > > > > request
> > > > > > > > > > header
> > > > > > > > > > > > > in
> > > > > > > > > > > > > > the future? The choice I see is duplicating the
> > field
> > > > in
> > > > > > the
> > > > > > > > new
> > > > > > > > > > request
> > > > > > > > > > > > > > header and the new ApiVersion request. But it's
> not
> > > > very
> > > > > > clean.
> > > > > > > > > > > > > > JR27.2 Requiring a major version API
> compatibility
> > KIP
> > > > is
> > > > > > also
> > > > > > > > a
> > > > > > > > > > bit
> > > > > > > > > > > > > > awkward.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Here is yet another proposal. We add the
> > > > ClientInstanceId
> > > > > > to
> > > > > > > > the
> > > > > > > > > > request
> > > > > > > > > > > > > > header as a tagged field and also bump up all
> > request
> > > > > > versions.
> > > > > > > > > > This
> > > > > > > > > > > > > avoids
> > > > > > > > > > > > > > the header compatibility issue in SocketServer.
> The
> > > > > > bumped-up
> > > > > > > > > > version
> > > > > > > > > > > > > > signals that the new field is actually required.
> > On the
> > > > > > server
> > > > > > > > > > side, when
> > > > > > > > > > > > > > receiving the new version of a request, we verify
> > that
> > > > the
> > > > > > > > > > > > > ClientInstanceId
> > > > > > > > > > > > > > field exists. If it's not present, we reject the
> > > > request.
> > > > > > This
> > > > > > > > > > will be
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > convention for adding future required fields to
> the
> > > > header.
> > > > > > > > > > Compared to
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > current proposal, this avoids duplicating the
> field
> > > > between
> > > > > > > > request
> > > > > > > > > > > > > header
> > > > > > > > > > > > > > and ApiVersionRequest, and it provides a path for
> > > > > > deprecating
> > > > > > > > the
> > > > > > > > > > older
> > > > > > > > > > > > > > version of the request header. What do you think?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Jun 24, 2026 at 2:15 AM Andrew Schofield
> <
> > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR27: Yes, I enhanced that section of the KIP.
> > > > > > > > > > > > > > > JR27.1: This KIP was unusual because we wanted
> to
> > > > add a
> > > > > > > > concept
> > > > > > > > > > which
> > > > > > > > > > > > > > > existed in the KIP-714 RPCs to the request
> > header,
> > > > > > > > complicating
> > > > > > > > > > the
> > > > > > > > > > > > > > > behavior of those RPCs, AND we wanted to change
> > the
> > > > > > handling
> > > > > > > > of
> > > > > > > > > > client
> > > > > > > > > > > > > ID
> > > > > > > > > > > > > > > without breaking older brokers. If we simply
> > wanted
> > > > to
> > > > > > add a
> > > > > > > > > > brand new
> > > > > > > > > > > > > > > field to the request header, we can do it as a
> > tagged
> > > > > > field
> > > > > > > > in
> > > > > > > > > > request
> > > > > > > > > > > > > > > header versions 2+.
> > > > > > > > > > > > > > > JR27.2: Covered this too. We'd need a major
> > version
> > > > API
> > > > > > > > > > compatibility
> > > > > > > > > > > > > KIP.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR31: Yes. KIP updated.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR32: Yes. This is a minor inconvenience I
> feel.
> > KIP
> > > > > > updated.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR33: I don't see the value of a string
> > comparison
> > > > here.
> > > > > > > > > > Personally,
> > > > > > > > > > > > > I'm
> > > > > > > > > > > > > > > happy with "assume".
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On 2026/06/23 22:52:15 Jun Rao via dev wrote:
> > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > JR27. The code that changed the request
> header
> > > > parsing
> > > > > > was
> > > > > > > > > > > > > introduced in
> > > > > > > > > > > > > > > > 2019 (
> > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> https://urldefense.com/v3/__https://github.com/apache/kafka/pull/7372__;!!Ayb5sqE7!scbWbTEEm2o-Y3MBGi829H2cpMWPRyrF9g2CW3lmRHyRmgBU2MyoRif2mFJpnfmvQ2x7fF4LrAJXdwH86ERR$
> > > > > > > > > > > > > > > ). I agree that fixing it
> > > > > > > > > > > > > > > > now is too late. We should document the path
> > > > forward
> > > > > > for
> > > > > > > > > > ApiVersion.
> > > > > > > > > > > > > > > Could
> > > > > > > > > > > > > > > > we answer at least the following questions in
> > the
> > > > > > > > > > Compatibility,
> > > > > > > > > > > > > > > > Deprecation, and Migration Plan section?
> > > > > > > > > > > > > > > > JR27.1 What happens to ApiVersion if we
> change
> > the
> > > > > > request
> > > > > > > > > > header in
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > future?
> > > > > > > > > > > > > > > > JR27.2 What happens if we ever want to
> > deprecate
> > > > v2 of
> > > > > > the
> > > > > > > > > > request
> > > > > > > > > > > > > > > header?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > JR28. The new MV needs to be covered in the
> > > > > > Compatibility,
> > > > > > > > > > > > > Deprecation,
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > Migration Plan section.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > JR31. "If a connection uses the v3 request
> > header
> > > > in
> > > > > > its
> > > > > > > > first
> > > > > > > > > > > > > request,
> > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > must specify a non-zero client instance ID
> and
> > it
> > > > must
> > > > > > > > specify
> > > > > > > > > > the
> > > > > > > > > > > > > same
> > > > > > > > > > > > > > > > client instance ID for all subsequent
> > requests."
> > > > > > > > > > > > > > > > Do we do the same if the first request is v6
> of
> > > > > > ApiVersion?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > JR32. "For subsequent requests using an
> earlier
> > > > > > version of
> > > > > > > > the
> > > > > > > > > > > > > request
> > > > > > > > > > > > > > > > header, the client sends the client ID". This
> > means
> > > > > > that
> > > > > > > > > > subsequent
> > > > > > > > > > > > > > > > ApiVersion V6 requests will carry the
> non-null
> > > > clientID
> > > > > > > > > > > > > unnecessarily.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > JR33. "After this KIP, the broker will assume
> > that
> > > > the
> > > > > > > > client
> > > > > > > > > > ID
> > > > > > > > > > > > > from the
> > > > > > > > > > > > > > > > initial request applies to all subsequent
> > requests
> > > > on a
> > > > > > > > > > connection,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > will ignore the client ID specified on any
> > > > subsequent
> > > > > > > > > > requests."
> > > > > > > > > > > > > > > > Should the broker verify that the clientId
> from
> > > > > > subsequent
> > > > > > > > > > request
> > > > > > > > > > > > > match
> > > > > > > > > > > > > > > > the first cached one, if not null?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >  Jun
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Tue, Jun 23, 2026 at 6:05 AM Andrew
> > Schofield <
> > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > Thanks for your reply.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > JR27: Unfortunately, I don't think this is
> > > > > > acceptable. We
> > > > > > > > > > would be
> > > > > > > > > > > > > > > saying
> > > > > > > > > > > > > > > > > that AK 4.5 clients can only connect to AK
> > 4.5 or
> > > > > > later
> > > > > > > > > > brokers,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > we'd create patch release for AK 4.0.x to
> AK
> > > > 4.4.x.
> > > > > > so
> > > > > > > > AK 4.5
> > > > > > > > > > > > > clients
> > > > > > > > > > > > > > > could
> > > > > > > > > > > > > > > > > connect to those too. We'd be preventing
> > > > connection
> > > > > > to
> > > > > > > > AK 3.x
> > > > > > > > > > > > > brokers
> > > > > > > > > > > > > > > by AK
> > > > > > > > > > > > > > > > > 4.5 clients. I don't see how we can break
> > > > > > compatibility
> > > > > > > > in a
> > > > > > > > > > minor
> > > > > > > > > > > > > > > release.
> > > > > > > > > > > > > > > > > Here's the existing compatibility table:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> https://urldefense.com/v3/__https://kafka.apache.org/41/getting-started/compatibility/__;!!Ayb5sqE7!ppWU_jI9f7EY9DYwcbiOESSBG2TmPn9CHfLnVM5TaIMwWqHUbUbIiGre1GGKMr-HmelQlyP6ibUSyORCAgte$
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > JR29: OK, makes sense to me.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On 2026/06/22 21:50:43 Jun Rao via dev
> wrote:
> > > > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > JR27. I am not sure I like the approach
> of
> > > > pinning
> > > > > > the
> > > > > > > > > > header to
> > > > > > > > > > > > > v2
> > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > ApiVersionsRequest. This means that in
> the
> > > > future,
> > > > > > each
> > > > > > > > > > change
> > > > > > > > > > > > > to the
> > > > > > > > > > > > > > > > > > request header must be duplicated in the
> > > > request
> > > > > > > > itself.
> > > > > > > > > > Here is
> > > > > > > > > > > > > an
> > > > > > > > > > > > > > > > > > alternative. Note that to detect an
> > unsupported
> > > > > > > > > > > > > ApiVersionRequest, we
> > > > > > > > > > > > > > > > > don't
> > > > > > > > > > > > > > > > > > need to parse the full v2 request header.
> > > > Parsing
> > > > > > the
> > > > > > > > > > first two
> > > > > > > > > > > > > > > fields
> > > > > > > > > > > > > > > > > > ApiKey and ApiVersion is enough. So, we
> > could
> > > > > > patch all
> > > > > > > > > > the 4.x
> > > > > > > > > > > > > > > releases
> > > > > > > > > > > > > > > > > > with a change that short-circuits parsing
> > the
> > > > full
> > > > > > > > request
> > > > > > > > > > header
> > > > > > > > > > > > > > > based
> > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > the first two fields. Then, we recommend
> > > > upgrading
> > > > > > > > from the
> > > > > > > > > > > > > latest
> > > > > > > > > > > > > > > 4.x
> > > > > > > > > > > > > > > > > > releases to future releases. This way, we
> > can
> > > > > > still let
> > > > > > > > > > > > > > > > > ApiVersionsRequest
> > > > > > > > > > > > > > > > > > depend on the request header for current
> > and
> > > > future
> > > > > > > > > > changes.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > JR29. The simplest thing is to upgrade
> the
> > > > KRaft
> > > > > > RPCs
> > > > > > > > too
> > > > > > > > > > to be
> > > > > > > > > > > > > > > > > consistent.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Sat, Jun 20, 2026 at 3:38 AM Andrew
> > > > Schofield <
> > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > > > Thanks for these insightful comments. I
> > did
> > > > > > > > prototype the
> > > > > > > > > > > > > earlier
> > > > > > > > > > > > > > > v2
> > > > > > > > > > > > > > > > > > > request header with tagged fields
> > variant. I
> > > > > > have now
> > > > > > > > > > > > > prototyped
> > > > > > > > > > > > > > > the v3
> > > > > > > > > > > > > > > > > > > request header variant.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > JR27: You were of course entirely
> correct
> > > > that a
> > > > > > new
> > > > > > > > > > version of
> > > > > > > > > > > > > > > > > > > ApiVersions request cannot use a
> request
> > > > header
> > > > > > > > which is
> > > > > > > > > > not
> > > > > > > > > > > > > > > > > > > binary-compatible with what has gone
> > before.
> > > > As a
> > > > > > > > > > result, I
> > > > > > > > > > > > > have
> > > > > > > > > > > > > > > > > introduced
> > > > > > > > > > > > > > > > > > > a new version of ApiVersions request
> > which
> > > > > > includes
> > > > > > > > > > > > > > > ClientInstanceId
> > > > > > > > > > > > > > > > > in the
> > > > > > > > > > > > > > > > > > > request body but continues to use the
> v2
> > > > request
> > > > > > > > header.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > JR28: Yes, we need a new metadata
> > version,
> > > > which
> > > > > > is
> > > > > > > > > > > > > provisionally
> > > > > > > > > > > > > > > > > > > IBP_4_5_IV0. I'll update the KIP with
> the
> > > > final
> > > > > > value
> > > > > > > > > > when it
> > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > assigned.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > JR29: I don't have any strong feelings
> on
> > > > this. I
> > > > > > > > > > suppose for
> > > > > > > > > > > > > each
> > > > > > > > > > > > > > > > > inter
> > > > > > > > > > > > > > > > > > > broker RPC version that is bumped, we
> > need to
> > > > > > > > introduce
> > > > > > > > > > an MV
> > > > > > > > > > > > > > > check. We
> > > > > > > > > > > > > > > > > > > cannot avoid this for RPCs which are
> also
> > > > used by
> > > > > > > > > > clients such
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > Fetch.
> > > > > > > > > > > > > > > > > > > For purely inter-broker RPCs, we could
> > just
> > > > > > exempt
> > > > > > > > them
> > > > > > > > > > from
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > version
> > > > > > > > > > > > > > > > > > > bump. What do you recommend here?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > JR30: Done. INVALID_REQUEST. I did
> > consider
> > > > > > > > permitting
> > > > > > > > > > zero
> > > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > > > instance ID for inter-broker
> connections,
> > > > but I
> > > > > > > > decided
> > > > > > > > > > that I
> > > > > > > > > > > > > > > > > preferred
> > > > > > > > > > > > > > > > > > > not creating another rule.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On 2026/06/17 22:45:07 Andrew Schofield
> > > > wrote:
> > > > > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > JR27: I am familiar with KIP-511 and
> > the
> > > > > > oddness of
> > > > > > > > > > > > > ApiVersions.
> > > > > > > > > > > > > > > You
> > > > > > > > > > > > > > > > > > > make an excellent point. I suspect that
> > > > > > > > > > ApiVersionsRequest will
> > > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > > > to be
> > > > > > > > > > > > > > > > > > > limited to the v2 request header, just
> > as it
> > > > is
> > > > > > > > > > restricted to
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > v0
> > > > > > > > > > > > > > > > > > > response header.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I'll do some experimentation.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On 2026/06/17 17:35:17 Jun Rao via
> dev
> > > > wrote:
> > > > > > > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Thanks for the reply. A few more
> > > > comments.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > JR27. It seems that we have a
> > > > compatibility
> > > > > > issue
> > > > > > > > > > with
> > > > > > > > > > > > > > > > > > > ApiVersionRequest v6
> > > > > > > > > > > > > > > > > > > > > depending on RequestHeader v3. This
> > > > happens
> > > > > > when
> > > > > > > > a
> > > > > > > > > > new
> > > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > issues
> > > > > > > > > > > > > > > > > > > > > ApiVersionRequest v6 to an old
> broker
> > > > (one
> > > > > > that
> > > > > > > > only
> > > > > > > > > > > > > supports
> > > > > > > > > > > > > > > > > > > > > ApiVersionRequest v5). The
> > SocketServer
> > > > in
> > > > > > the
> > > > > > > > > > broker will
> > > > > > > > > > > > > > > first
> > > > > > > > > > > > > > > > > try to
> > > > > > > > > > > > > > > > > > > > > read the request header. It tries
> to
> > > > find the
> > > > > > > > header
> > > > > > > > > > > > > version
> > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > request version. Since the broker
> > doesn't
> > > > > > know
> > > > > > > > > > > > > > > ApiVersionRequest
> > > > > > > > > > > > > > > > > v6, it
> > > > > > > > > > > > > > > > > > > > > uses v2 to parse the request
> header.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > The v2's wire format for the
> request
> > > > header
> > > > > > is:
> > > > > > > > > > ApiKey |
> > > > > > > > > > > > > > > > > ApiVersion |
> > > > > > > > > > > > > > > > > > > > > CorrelationId | ClientId |
> > > > > > tagged-fields-varint
> > > > > > > > > > > > > > > > > > > > > The v3's wire format for the
> request
> > > > header
> > > > > > is:
> > > > > > > > > > ApiKey |
> > > > > > > > > > > > > > > > > ApiVersion |
> > > > > > > > > > > > > > > > > > > > > CorrelationId | ClientId |
> > > > > > ClientInstanceId(16
> > > > > > > > > > bytes) |
> > > > > > > > > > > > > > > > > tagged-fields
> > > > > > > > > > > > > > > > > > > varint
> > > > > > > > > > > > > > > > > > > > > The first 4 fields are identical,
> > > > allowing
> > > > > > the
> > > > > > > > > > broker to
> > > > > > > > > > > > > parse
> > > > > > > > > > > > > > > > > them.
> > > > > > > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > > > > > > broker then tries to read the
> > > > > > > > tagged-fields-varint
> > > > > > > > > > using
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > serialized
> > > > > > > > > > > > > > > > > > > > > bytes intended for
> ClientInstanceId.
> > This
> > > > > > could
> > > > > > > > lead
> > > > > > > > > > to a
> > > > > > > > > > > > > > > parsing
> > > > > > > > > > > > > > > > > > > error and
> > > > > > > > > > > > > > > > > > > > > raise an invalid request error. The
> > > > broker
> > > > > > will
> > > > > > > > > > close the
> > > > > > > > > > > > > > > > > connection
> > > > > > > > > > > > > > > > > > > > > instead of sending a v0 response
> for
> > > > > > > > > > ApiVersionRequest.
> > > > > > > > > > > > > Then
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > > > > > will never be able to detect
> > supported
> > > > API
> > > > > > > > versions
> > > > > > > > > > on the
> > > > > > > > > > > > > old
> > > > > > > > > > > > > > > > > broker.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > The same problem didn't exist when
> > > > > > > > ApiVersionRequest
> > > > > > > > > > > > > changed
> > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > v1
> > > > > > > > > > > > > > > > > > > > > request header to v2 because the
> wire
> > > > format
> > > > > > for
> > > > > > > > v1
> > > > > > > > > > is a
> > > > > > > > > > > > > > > prefix of
> > > > > > > > > > > > > > > > > v2.
> > > > > > > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > > > > > > problem exists for this KIP because
> > the
> > > > wire
> > > > > > > > format
> > > > > > > > > > of v2
> > > > > > > > > > > > > is no
> > > > > > > > > > > > > > > > > longer
> > > > > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > > > > prefix of v3.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > JR28. Since we are bumping up the
> > > > version of
> > > > > > > > inter
> > > > > > > > > > broker
> > > > > > > > > > > > > > > > > requests, we
> > > > > > > > > > > > > > > > > > > need
> > > > > > > > > > > > > > > > > > > > > to gate them by introducing a new
> MV.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > JR29. Could you specify whether the
> > > > version
> > > > > > for
> > > > > > > > > > KRaft PRCs
> > > > > > > > > > > > > > > will be
> > > > > > > > > > > > > > > > > > > bumped
> > > > > > > > > > > > > > > > > > > > > too?
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > JR30. "If a connection uses the v3
> > > > request
> > > > > > > > header in
> > > > > > > > > > its
> > > > > > > > > > > > > first
> > > > > > > > > > > > > > > > > > > request, it
> > > > > > > > > > > > > > > > > > > > > must specify a non-zero client
> > instance
> > > > ID"
> > > > > > > > > > > > > > > > > > > > > Could we define the broker's
> behavior
> > > > when a
> > > > > > v3
> > > > > > > > > > request
> > > > > > > > > > > > > header
> > > > > > > > > > > > > > > > > > > contains a 0
> > > > > > > > > > > > > > > > > > > > > client instance ID?
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Tue, Jun 16, 2026 at 1:25 AM
> > Andrew
> > > > > > Schofield
> > > > > > > > <
> > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > JR26: Yes, I was considering
> > open-ended
> > > > > > version
> > > > > > > > > > ranges.
> > > > > > > > > > > > > I've
> > > > > > > > > > > > > > > > > updated
> > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > KIP.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Now that we have a new request
> > header
> > > > > > version,
> > > > > > > > I
> > > > > > > > > > think
> > > > > > > > > > > > > it's
> > > > > > > > > > > > > > > safe
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > reintroduce the client ID
> > optimisation.
> > > > > > I've
> > > > > > > > added
> > > > > > > > > > that
> > > > > > > > > > > > > into
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > KIP
> > > > > > > > > > > > > > > > > > > also.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Let me know what you think.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On 2026/06/15 17:46:00 Jun Rao
> via
> > dev
> > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Thanks for the reply. Just a
> > minor
> > > > > > comment.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > JR26. "The keys of the map are
> > either
> > > > > > single
> > > > > > > > > > versions
> > > > > > > > > > > > > like
> > > > > > > > > > > > > > > "0"
> > > > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > > > > closed
> > > > > > > > > > > > > > > > > > > > > > > version ranges like "1-2"."
> > > > > > > > > > > > > > > > > > > > > > > It will be useful to support
> > > > open-ended
> > > > > > > > > > versions. That
> > > > > > > > > > > > > way,
> > > > > > > > > > > > > > > > > "3":
> > > > > > > > > > > > > > > > > > > "3"
> > > > > > > > > > > > > > > > > > > > > > could
> > > > > > > > > > > > > > > > > > > > > > > be "3+": "3". This part won't
> > need to
> > > > > > change
> > > > > > > > in
> > > > > > > > > > the
> > > > > > > > > > > > > future
> > > > > > > > > > > > > > > > > when we
> > > > > > > > > > > > > > > > > > > bump
> > > > > > > > > > > > > > > > > > > > > > up
> > > > > > > > > > > > > > > > > > > > > > > the request version without
> > changing
> > > > the
> > > > > > > > header.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > On Fri, Jun 12, 2026 at 2:12 PM
> > > > Andrew
> > > > > > > > Schofield
> > > > > > > > > > <
> > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > JR25: I agree. I've changed
> to
> > a
> > > > > > > > > > headerVersions map
> > > > > > > > > > > > > in
> > > > > > > > > > > > > > > both
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > request
> > > > > > > > > > > > > > > > > > > > > > > > and response schemas.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Let me know what you think.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > On 2026/06/12 03:39:39 Jun
> Rao
> > via
> > > > dev
> > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Thanks for the updated KIP.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > JR25. I have some concerns
> > about
> > > > > > adding
> > > > > > > > the
> > > > > > > > > > > > > > > > > > > clientInstanceIdVersions
> > > > > > > > > > > > > > > > > > > > > > > > field
> > > > > > > > > > > > > > > > > > > > > > > > > to the schema. First of
> all,
> > it
> > > > only
> > > > > > > > applies
> > > > > > > > > > to
> > > > > > > > > > > > > > > requests,
> > > > > > > > > > > > > > > > > but
> > > > > > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > > > > > > > > > responses. So, it's a bit
> > weird
> > > > to
> > > > > > add
> > > > > > > > it to
> > > > > > > > > > the
> > > > > > > > > > > > > > > general
> > > > > > > > > > > > > > > > > > > schema.
> > > > > > > > > > > > > > > > > > > > > > > > Secondly,
> > > > > > > > > > > > > > > > > > > > > > > > > it's very specific to the
> new
> > > > field
> > > > > > > > added to
> > > > > > > > > > the
> > > > > > > > > > > > > > > request
> > > > > > > > > > > > > > > > > > > header. If
> > > > > > > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > > > > > > change the request header
> > again
> > > > in
> > > > > > the
> > > > > > > > > > future, we
> > > > > > > > > > > > > need
> > > > > > > > > > > > > > > > > another
> > > > > > > > > > > > > > > > > > > way
> > > > > > > > > > > > > > > > > > > > > > to map
> > > > > > > > > > > > > > > > > > > > > > > > > request versions to the new
> > > > header
> > > > > > > > version.
> > > > > > > > > > > > > Ideally, we
> > > > > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > > > > > have a
> > > > > > > > > > > > > > > > > > > > > > > > > generic way to map request
> > > > versions
> > > > > > to
> > > > > > > > all
> > > > > > > > > > future
> > > > > > > > > > > > > > > header
> > > > > > > > > > > > > > > > > > > versions.
> > > > > > > > > > > > > > > > > > > > > > One
> > > > > > > > > > > > > > > > > > > > > > > > > possibility is to
> introduce a
> > > > > > > > headerVersion
> > > > > > > > > > field
> > > > > > > > > > > > > in
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > schema.
> > > > > > > > > > > > > > > > > > > > > > Then,
> > > > > > > > > > > > > > > > > > > > > > > > each
> > > > > > > > > > > > > > > > > > > > > > > > > request/response can use
> this
> > > > field
> > > > > > to
> > > > > > > > map
> > > > > > > > > > its
> > > > > > > > > > > > > > > versions to
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > header
> > > > > > > > > > > > > > > > > > > > > > > > > versions.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jun 9, 2026 at
> > 4:55 AM
> > > > Andrew
> > > > > > > > > > Schofield <
> > > > > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Hi Matthias,
> > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > I have change the version
> > > > property
> > > > > > for
> > > > > > > > > > > > > introducing
> > > > > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > > > > > ID
> > > > > > > > > > > > > > > > > > > > > > > > into
> > > > > > > > > > > > > > > > > > > > > > > > > > the request headers to be
> > > > > > > > > > > > > `clientInstanceIdVersions`
> > > > > > > > > > > > > > > > > which
> > > > > > > > > > > > > > > > > > > is now
> > > > > > > > > > > > > > > > > > > > > > an
> > > > > > > > > > > > > > > > > > > > > > > > > > open-ended range, such as
> > "3+",
> > > > > > more
> > > > > > > > > > closely
> > > > > > > > > > > > > matching
> > > > > > > > > > > > > > > > > what
> > > > > > > > > > > > > > > > > > > we have
> > > > > > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > > > > > > flexible versions.
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > I also added a change to
> > the
> > > > > > > > > > > > > > > > > > > RebalanceConsumer.clientInstanceId
> > > > > > > > > > > > > > > > > > > > > > method
> > > > > > > > > > > > > > > > > > > > > > > > > > introduced in KIP-1306.
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > On 2026/06/03 18:31:06
> > > > "Matthias J.
> > > > > > > > Sax"
> > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks Andrew.
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >  From a KIP-714
> > perspective,
> > > > > > this is
> > > > > > > > a
> > > > > > > > > > great
> > > > > > > > > > > > > > > change,
> > > > > > > > > > > > > > > > > as it
> > > > > > > > > > > > > > > > > > > make
> > > > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > new
> > > > > > > > > > > > > > > > > > > > > > > > > > > RPCs and client/broker
> > > > > > cross-version
> > > > > > > > > > > > > compatibility
> > > > > > > > > > > > > > > > > clean.
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > One question about your
> > > > > > > > `DeleteGroups`
> > > > > > > > > > RPC
> > > > > > > > > > > > > example.
> > > > > > > > > > > > > > > > > Should
> > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > new
> > > > > > > > > > > > > > > > > > > > > > > > > > > version of the RPC say
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > "clientInstanceIdVersion":
> > > > > > "3+",
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > ie, 3+ instead of 3?
> > Similar
> > > > for
> > > > > > > > other
> > > > > > > > > > request,
> > > > > > > > > > > > > > > which
> > > > > > > > > > > > > > > > > > > don't use
> > > > > > > > > > > > > > > > > > > > > > `+`
> > > > > > > > > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> `clientInstanceIdVersion`
> > > > field.
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -Matthias
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > On 6/2/26 7:42 AM,
> Andrew
> > > > > > Schofield
> > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Following on from the
> > > > > > discussion
> > > > > > > > in the
> > > > > > > > > > > > > > > community,
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > difficulty
> > > > > > > > > > > > > > > > > > > > > > > > > > of trying to accommodate
> > the
> > > > client
> > > > > > > > > > instance ID
> > > > > > > > > > > > > in a
> > > > > > > > > > > > > > > > > tagged
> > > > > > > > > > > > > > > > > > > field
> > > > > > > > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > > > > > > > > > acceptable complexity, I
> > have
> > > > made
> > > > > > a
> > > > > > > > > > significant
> > > > > > > > > > > > > > > change
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > the KIP.
> > > > > > > > > > > > > > > > > > > > > > > > Now, it
> > > > > > > > > > > > > > > > > > > > > > > > > > introduces v3 of the
> > request
> > > > header
> > > > > > > > > > containing
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > > > > > ID
> > > > > > > > > > > > > > > > > > > > > > > > as a
> > > > > > > > > > > > > > > > > > > > > > > > > > proper field.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/KAFKA/KIP-1313*3A*Client*instance*ID*in*all*request*headers__;JSsrKysrKys!!Ayb5sqE7!pUZS25PuTKdhiqvTGcwDKbclqpG8dFOzw2Ax9WxVM6Sb09PVQ0gl1i0gjlr2_Krr66agbuVC2qLGgUcg7vrW$
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Please review and let
> > me
> > > > know
> > > > > > what
> > > > > > > > you
> > > > > > > > > > think.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2026/05/28
> 21:51:01
> > > > > > "Matthias J.
> > > > > > > > > > Sax"
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> Thanks Andrew. I
> > agree to
> > > > the
> > > > > > > > issue
> > > > > > > > > > that
> > > > > > > > > > > > > tagged
> > > > > > > > > > > > > > > > > fields
> > > > > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > > > > > > optional.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> Nevertheless, I find
> > the
> > > > > > proposed
> > > > > > > > > > > > > compatibility
> > > > > > > > > > > > > > > > > > > protocol too
> > > > > > > > > > > > > > > > > > > > > > > > complex
> > > > > > > > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> unnecessary, and
> would
> > > > still
> > > > > > > > prefer a
> > > > > > > > > > > > > version
> > > > > > > > > > > > > > > bump
> > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > `GetTelemetrySubscriptionsRequest/Reponse`
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > clean
> > > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > > > > > > > > up. --
> > > > > > > > > > > > > > > > > > > > > > > > For
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > `PushTelemetryRequest` the
> > > > > > > > argument
> > > > > > > > > > from
> > > > > > > > > > > > > above
> > > > > > > > > > > > > > > > > applies,
> > > > > > > > > > > > > > > > > > > so
> > > > > > > > > > > > > > > > > > > > > > > > leaving it
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> untouched is ok.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> I don't see why
> > > > > > > > > > > > > > > `GetTelemetrySubscriptionsRequest`
> > > > > > > > > > > > > > > > > > > would need
> > > > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > > > > > encode
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> the
> `clientInstandId`
> > in
> > > > it's
> > > > > > > > request
> > > > > > > > > > body.
> > > > > > > > > > > > > > > Given
> > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> `clientInstanceId`
> is
> > a
> > > > random
> > > > > > > > UUID,
> > > > > > > > > > the
> > > > > > > > > > > > > > > returned
> > > > > > > > > > > > > > > > > > > subscription
> > > > > > > > > > > > > > > > > > > > > > > > cannot
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> really depend on it.
> > So
> > > > why
> > > > > > would
> > > > > > > > we
> > > > > > > > > > need to
> > > > > > > > > > > > > > > send
> > > > > > > > > > > > > > > > > it to
> > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > broker?
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> Right now, it's set
> to
> > > > ZERO
> > > > > > only
> > > > > > > > for
> > > > > > > > > > the
> > > > > > > > > > > > > > > purpose to
> > > > > > > > > > > > > > > > > get
> > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > broker to
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> assign a new UUID.
> > But it
> > > > has
> > > > > > > > nothing
> > > > > > > > > > to do
> > > > > > > > > > > > > > > with the
> > > > > > > > > > > > > > > > > > > actual
> > > > > > > > > > > > > > > > > > > > > > "what
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> metrics should I
> send"
> > > > > > question.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> To be fair, KIP-714
> > lists
> > > > > > > > > > > > > `client_instance_id`
> > > > > > > > > > > > > > > as a
> > > > > > > > > > > > > > > > > > > field that
> > > > > > > > > > > > > > > > > > > > > > > > can be
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> used to define a
> > > > subscription.
> > > > > > > > But it
> > > > > > > > > > seems
> > > > > > > > > > > > > > > rather
> > > > > > > > > > > > > > > > > > > useless in
> > > > > > > > > > > > > > > > > > > > > > > > practice
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> to me? I a user
> > defines a
> > > > > > > > > > subscription, they
> > > > > > > > > > > > > > > cannot
> > > > > > > > > > > > > > > > > > > know the
> > > > > > > > > > > > > > > > > > > > > > UUID.
> > > > > > > > > > > > > > > > > > > > > > > > > > Thus,
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> I think we should
> > actually
> > > > > > drop
> > > > > > > > > > supporting
> > > > > > > > > > > > > > > > > > > > > > `client_instance_id`
> > > > > > > > > > > > > > > > > > > > > > > > as a
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> "subscription
> matching
> > > > > > > > parameter"? Of
> > > > > > > > > > > > > course,
> > > > > > > > > > > > > > > there
> > > > > > > > > > > > > > > > > is a
> > > > > > > > > > > > > > > > > > > > > > backward
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> compatibility
> > question,
> > > > but I
> > > > > > > > think
> > > > > > > > > > we can
> > > > > > > > > > > > > > > address
> > > > > > > > > > > > > > > > > > > this: if
> > > > > > > > > > > > > > > > > > > > > > > > brokers
> > > > > > > > > > > > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> upgraded and they
> > have an
> > > > > > existing
> > > > > > > > > > > > > > > > > `client_instance_id`
> > > > > > > > > > > > > > > > > > > based
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> subscription
> defined,
> > they
> > > > > > could
> > > > > > > > > > advertise
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > only
> > > > > > > > > > > > > > > > > > > support
> > > > > > > > > > > > > > > > > > > > > > v0, and
> > > > > > > > > > > > > > > > > > > > > > > > > > they
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> should log a warning
> > that
> > > > this
> > > > > > > > > > feature is
> > > > > > > > > > > > > > > > > deprecated.
> > > > > > > > > > > > > > > > > > > New
> > > > > > > > > > > > > > > > > > > > > > brokers
> > > > > > > > > > > > > > > > > > > > > > > > > > would
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> also not allow to
> use
> > > > > > > > > > `client_instance_id`
> > > > > > > > > > > > > any
> > > > > > > > > > > > > > > > > longer to
> > > > > > > > > > > > > > > > > > > > > > define a
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> subscription.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> Similarly, for
> > > > > > > > > > > > > > > `GetTelemetrySubscriptionsResponse`,
> > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > only
> > > > > > > > > > > > > > > > > > > > > > need
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> `clientInstanceId`
> if
> > the
> > > > > > broker
> > > > > > > > > > computes
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > UUID.
> > > > > > > > > > > > > > > > > But
> > > > > > > > > > > > > > > > > > > if we
> > > > > > > > > > > > > > > > > > > > > > let
> > > > > > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> client compute it,
> > this
> > > > field
> > > > > > is
> > > > > > > > not
> > > > > > > > > > needed
> > > > > > > > > > > > > any
> > > > > > > > > > > > > > > > > longer.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> -Matthias
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> On 5/28/26 1:21 AM,
> > Andrew
> > > > > > > > Schofield
> > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>> Hi Jun,
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>> Thanks for your
> > response.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>> JR24: I'll update
> > the KIP
> > > > > > > > shortly.
> > > > > > > > > > Here's a
> > > > > > > > > > > > > > > > > summary.
> > > > > > > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > > > > > > > various
> > > > > > > > > > > > > > > > > > > > > > > > > > modern group protocol
> > heartbeat
> > > > > > > > requests
> > > > > > > > > > encode
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > member
> > > > > > > > > > > > > > > > > > > ID as a
> > > > > > > > > > > > > > > > > > > > > > > > string
> > > > > > > > > > > > > > > > > > > > > > > > > > for historical reasons,
> > even
> > > > though
> > > > > > > > it's in
> > > > > > > > > > > > > practice
> > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > UUID.
> > > > > > > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > > > > > > > Apache
> > > > > > > > > > > > > > > > > > > > > > > > > > Kafka Java client happens
> > to
> > > > use
> > > > > > > > > > > > > > > > > > > org.apache.kafka.common.Uuid to
> > > > > > > > > > > > > > > > > > > > > > > > create the
> > > > > > > > > > > > > > > > > > > > > > > > > > member ID and convert it
> > into a
> > > > > > string.
> > > > > > > > > > This
> > > > > > > > > > > > > means
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > when
> > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > > > clientInstanceId is
> > converted
> > > > into
> > > > > > a
> > > > > > > > > > string, its
> > > > > > > > > > > > > > > encoding
> > > > > > > > > > > > > > > > > > > matches
> > > > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > > > member ID and it all
> lines
> > up.
> > > > > > However,
> > > > > > > > > > there are
> > > > > > > > > > > > > > > other
> > > > > > > > > > > > > > > > > ways
> > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > encode
> > > > > > > > > > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > > > > > > > > > UUID into a string and I
> > know
> > > > for a
> > > > > > > > fact
> > > > > > > > > > that the
> > > > > > > > > > > > > > > > > librdkafka
> > > > > > > > > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > > > > > > > > does it
> > > > > > > > > > > > > > > > > > > > > > > > > > differently.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>> Thanks,
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>> Andrew
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>> On 2026/05/27
> > 17:11:25
> > > > Jun
> > > > > > Rao
> > > > > > > > via
> > > > > > > > > > dev
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> Hi, Andrew,
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> Thanks for the
> > reply.
> > > > One
> > > > > > more
> > > > > > > > > > comment.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> JR24. "The
> > alignment of
> > > > > > other
> > > > > > > > > > identifiers
> > > > > > > > > > > > > is
> > > > > > > > > > > > > > > by
> > > > > > > > > > > > > > > > > > > convention
> > > > > > > > > > > > > > > > > > > > > > (and
> > > > > > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > > > Java
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> client will follow
> > the
> > > > > > > > convention)
> > > > > > > > > > rather
> > > > > > > > > > > > > than
> > > > > > > > > > > > > > > > > > > mandate."
> > > > > > > > > > > > > > > > > > > > > > Could
> > > > > > > > > > > > > > > > > > > > > > > > you
> > > > > > > > > > > > > > > > > > > > > > > > > > describe
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> the convention to
> > > > convert a
> > > > > > > > > > > > > clientInstanceId
> > > > > > > > > > > > > > > > > (UUID)
> > > > > > > > > > > > > > > > > > > to a
> > > > > > > > > > > > > > > > > > > > > > > > memberId
> > > > > > > > > > > > > > > > > > > > > > > > > > (String)?
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> Jun
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> On Tue, May 19,
> > 2026 at
> > > > > > 2:36 AM
> > > > > > > > > > Andrew
> > > > > > > > > > > > > > > Schofield <
> > > > > > > > > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> 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 <
> > > > > > > > > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>> 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 <
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>
> > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> 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 <
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>
> > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> 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
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] KIP-1313: Client instance ID in all request headers

[Luke Chen <sh...@gmail.com>]

Hi Andrew,

Thanks for the KIP.

LC1. It looks like in the KIP, we always assume the client firstly connects
to broker node. So what about the admin client directly queries the
controller node via "bootstrap.controller" option? Does this KIP also apply
to this client -> controller connections? I think so, right?


Thanks,
Luke

On Fri, Aug 7, 2026 at 1:20 AM Jun Rao via dev <de...@kafka.apache.org> wrote:

> Hi, Andrew,
>
> Thanks for the reply.
>
> JR39. There is still some inconsistency.
> For clientInstanceID, we reject any subsequent requests which specify a
> different value for the client instance ID. But for clientID, we reject
> subsequent requests if the client ID is specified (request header v3 or
> later).
>
> Jun
>
>
> On Thu, Aug 6, 2026 at 12:47 AM Andrew Schofield <sc...@apache.org>
> wrote:
>
> > Hi Jun,
> > Thanks for your reply.
> >
> > JR39: KIP description tightened up. That should do the trick.
> >
> > Thanks,
> > Andrew
> >
> > On 2026/08/05 17:28:34 Jun Rao via dev wrote:
> > > Hi, Andrew,
> > >
> > > Thanks for the reply.
> > >
> > > JR39. For clientInstanceID, we have: "If a client specifies a reserved
> > > client instance ID (zero or one), the request will be rejected with
> error
> > > code INVALID_REQUEST ."
> > > For clientId, we have: "After this KIP, the broker will assume that the
> > > client ID from the initial request applies to all subsequent requests
> > > on a connection,
> > > and it will ignore the client ID specified on any subsequent requests."
> > > Could we make the behavior consistent between these two?
> > >
> > > Jun
> > >
> > >
> > > On Tue, Aug 4, 2026 at 1:05 PM Andrew Schofield <schofielaj@apache.org
> >
> > > wrote:
> > >
> > > > Hi Jun,
> > > > Thanks for the reply.
> > > >
> > > > JR37: It had escaped me that ClientInstanceId is a tagged field, so
> > you're
> > > > absolutely right. (I am not an AI.) I'll update the KIP.
> > > >
> > > > Thanks,
> > > > Andrew
> > > >
> > > > On 2026/08/04 18:24:19 Jun Rao via dev wrote:
> > > > > Hi, Andrew,
> > > > >
> > > > > Thanks for the reply.
> > > > >
> > > > > JR37. UUID is 16 bytes. If it's omitted in subsequent requests, we
> > save
> > > > 16
> > > > > bytes, right?
> > > > >
> > > > > Jun
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Aug 4, 2026 at 5:47 AM Andrew Schofield <
> > schofielaj@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Hi Jun,
> > > > > > Thanks for your reply.
> > > > > >
> > > > > > JR37: Unlike with clientId where space is saved by not
> > transmitting it
> > > > on
> > > > > > every request, there's nothing to be gained by omitting
> > > > clientInstanceId on
> > > > > > later requests. I prefer to leave it as is.
> > > > > >
> > > > > > JR38: OK, I've updated those paragraphs in the KIP to exclude the
> > > > reserved
> > > > > > UUIDs.
> > > > > >
> > > > > > Thanks,
> > > > > > Andrew
> > > > > >
> > > > > > On 2026/08/03 20:23:39 Jun Rao via dev wrote:
> > > > > > > Hi, Andrew,
> > > > > > >
> > > > > > > Thanks for the reply.
> > > > > > >
> > > > > > > JR37. Will it be better to require ClientInstanceId only on the
> > first
> > > > > > > request, to be consistent with clientId?
> > > > > > >
> > > > > > > JR38. "must specify a non-zero client instance ID". one_uuid is
> > also
> > > > a
> > > > > > > reserved one in the Uuid class. Should we exclude that one too?
> > > > > > >
> > > > > > > Jun
> > > > > > >
> > > > > > > On Fri, Jul 31, 2026 at 9:10 AM Andrew Schofield <
> > > > schofielaj@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi Jun,
> > > > > > > > Thanks for the reply and sorry for the delay. Lots of 4.4
> stuff
> > > > got in
> > > > > > the
> > > > > > > > way.
> > > > > > > >
> > > > > > > > JR34: EligibleLeaderReplicasVersion and KRaftVersion also use
> > > > > > ApiVersion
> > > > > > > > to negotiate the RPC versions. I do not believe we need to
> > bump up
> > > > > > other
> > > > > > > > feature versions as a result of the RPC version bumps in this
> > KIP.
> > > > > > > >
> > > > > > > > JR35: Yes, good catch. In order to handle client ID-based
> > quotas
> > > > for
> > > > > > > > forwarded requests, it will be necessary to populate the
> > client ID
> > > > in
> > > > > > the
> > > > > > > > forwarded request header. KIP updated.
> > > > > > > >
> > > > > > > > JR36: I hadn't considered MV to be a feature version, but I
> > > > understand.
> > > > > > > > KIP updated.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Andrew
> > > > > > > >
> > > > > > > > On 2026/06/29 16:23:09 Jun Rao via dev wrote:
> > > > > > > > > Hi, Andrew,
> > > > > > > > >
> > > > > > > > > Thanks for the reply.
> > > > > > > > >
> > > > > > > > > JR34. Transaction coordinator uses ApiVersion to negotiate
> > the
> > > > PRC
> > > > > > > > > versions. Therefore, if there is no functional change,
> there
> > is
> > > > no
> > > > > > need
> > > > > > > > to
> > > > > > > > > bump the TV version. I am not sure about
> > > > > > EligibleLeaderReplicasVersion
> > > > > > > > > and KRaftVersion.
> > > > > > > > > It would be useful to have the experts chime in.
> > > > > > > > >
> > > > > > > > > JR35. Envelope/forwarding interaction: When a broker
> > forwards a
> > > > > > client
> > > > > > > > > request to the controller via EnvelopeUtils
> > > > > > > > (parseForwardedRequestHeader),
> > > > > > > > > the inner header may have its clientId optimized to null.
> > Some
> > > > quota
> > > > > > > > > enforcement (e.g. controller mutation) may depend on the
> > non-null
> > > > > > > > clientId.
> > > > > > > > > The per-connection caching occurs on the original
> > client↔broker
> > > > > > > > connection, not
> > > > > > > > > the broker↔controller one. Should the forwarded request
> > preserve
> > > > the
> > > > > > > > > non-null resolved (cached) client.id?
> > > > > > > > >
> > > > > > > > > JR36. "This KIP does not need to introduce any feature
> > version
> > > > > > bumps."
> > > > > > > > This
> > > > > > > > > is not very accurate since MV is a feature version and is
> > bumped.
> > > > > > > > >
> > > > > > > > > Jun
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Fri, Jun 26, 2026 at 12:42 AM Andrew Schofield <
> > > > > > schofielaj@apache.org
> > > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi Jun,
> > > > > > > > > > I've updated the KIP.
> > > > > > > > > >
> > > > > > > > > > JS34: I don't believe that we need to introduce any new
> > feature
> > > > > > > > versions
> > > > > > > > > > for this KIP. For example, we do not need a new
> > ShareVersion
> > > > since
> > > > > > that
> > > > > > > > > > enabled share groups (SV_1) and controls the versioning
> of
> > the
> > > > > > records
> > > > > > > > on
> > > > > > > > > > the internal topics (SV_2). I think the same applies for
> > the
> > > > > > others. I
> > > > > > > > > > understand GroupVersion and StreamsVersion, and I think
> > they
> > > > > > follow the
> > > > > > > > > > same reasoning as ShareVersion. I don't know
> > > > TransactionVersion or
> > > > > > > > > > EligibleLeaderReplicasVersion, so let me know whether
> > those are
> > > > > > > > different
> > > > > > > > > > in this regard.
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > Andrew
> > > > > > > > > >
> > > > > > > > > > On 2026/06/25 21:32:27 Andrew Schofield wrote:
> > > > > > > > > > > Hi Jun,
> > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > >
> > > > > > > > > > > JR27: Yes, makes sense. So request header v3 is
> > > > binary-compatible
> > > > > > > > with
> > > > > > > > > > request header v2.
> > > > > > > > > > >
> > > > > > > > > > > JS34: Yes, I think so.
> > > > > > > > > > >
> > > > > > > > > > > I'll update the KIP tomorrow morning.
> > > > > > > > > > >
> > > > > > > > > > > Thanks,
> > > > > > > > > > > Andrew
> > > > > > > > > > >
> > > > > > > > > > > On 2026/06/25 20:23:57 Jun Rao via dev wrote:
> > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > >
> > > > > > > > > > > > JR27. I was thinking of the following, which is
> > slightly
> > > > > > different
> > > > > > > > from
> > > > > > > > > > > > what you described.
> > > > > > > > > > > > * Bump RequestHeader to v3, and introduce
> > ClientInstanceId
> > > > as a
> > > > > > > > tagged
> > > > > > > > > > > > field for versions 3+ and change the semantic of the
> > > > existing
> > > > > > field
> > > > > > > > > > > > clientId (only need to be populated by the first
> > request).
> > > > > > > > > > > > * Bump the request versions for all RPCs including
> > > > ApiVersion
> > > > > > and
> > > > > > > > map
> > > > > > > > > > to
> > > > > > > > > > > > the new version to use v3 of RequestHeader.
> > > > > > > > > > > > * On the server side, when a new request version is
> > seen,
> > > > we
> > > > > > > > enforce
> > > > > > > > > > the
> > > > > > > > > > > > presence of ClientInstanceId and reject the request
> if
> > it
> > > > is
> > > > > > > > missing.
> > > > > > > > > > > > Essentially, treat it as a required field. We also
> > cache
> > > > the
> > > > > > > > clientId
> > > > > > > > > > from
> > > > > > > > > > > > the first request and ignore it from subsequent ones.
> > > > > > > > > > > > * We would introduce OffsetDelete v1 as the first
> > flexible
> > > > > > version
> > > > > > > > so
> > > > > > > > > > that
> > > > > > > > > > > > it uses the v3 request header.
> > > > > > > > > > > > * We would update PushTelemetry and
> > > > GetTelemetrySubscriptions
> > > > > > as
> > > > > > > > > > described
> > > > > > > > > > > > in the KIP and the ClientInstanceId would move to the
> > > > request
> > > > > > > > header.
> > > > > > > > > > > >
> > > > > > > > > > > > In the future, if we want to add a new truly optional
> > > > field to
> > > > > > > > > > > > RequestHeader, we can continue adding it as a tagged
> > field
> > > > > > without
> > > > > > > > > > bumping
> > > > > > > > > > > > up the request version. To add a required field, we
> > will
> > > > add
> > > > > > it as
> > > > > > > > a
> > > > > > > > > > tagged
> > > > > > > > > > > > field but force a version bump to all requests.
> > > > > > > > > > > >
> > > > > > > > > > > > The benefit of this approach is that (1) it's
> > compatible
> > > > with
> > > > > > the
> > > > > > > > > > format of
> > > > > > > > > > > > the old request header; (2) it avoids duplicating new
> > > > fields;
> > > > > > and
> > > > > > > > (3)
> > > > > > > > > > there
> > > > > > > > > > > > is no constraint on deprecating the old request
> header.
> > > > It's
> > > > > > > > slightly
> > > > > > > > > > weird
> > > > > > > > > > > > to bump up the version when adding a tagged field.
> But
> > it
> > > > still
> > > > > > > > seems
> > > > > > > > > > > > better than the alternatives.
> > > > > > > > > > > >
> > > > > > > > > > > > JR34. Since we now have different feature versions
> > gating
> > > > > > different
> > > > > > > > > > RPCs,
> > > > > > > > > > > > should we bump up GV, TV, etc., too?
> > > > > > > > > > > >
> > > > > > > > > > > > Jun
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Jun 25, 2026 at 10:37 AM Andrew Schofield <
> > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > > >
> > > > > > > > > > > > > JR27.1: What if we want to add non-optional fields
> > to the
> > > > > > request
> > > > > > > > > > header
> > > > > > > > > > > > > in the future? I think that such fields would be by
> > > > > > definition
> > > > > > > > future
> > > > > > > > > > > > > fields which would not be understood by existing
> > > > brokers. For
> > > > > > > > > > serialization
> > > > > > > > > > > > > reasons, I think we would use version 2+ tagged
> > fields
> > > > and
> > > > > > the
> > > > > > > > > > requirement
> > > > > > > > > > > > > for non-optionality would be enforced by code,
> rather
> > > > than
> > > > > > by the
> > > > > > > > > > protocol
> > > > > > > > > > > > > schema. This avoids the field duplication.
> > > > > > > > > > > > >
> > > > > > > > > > > > > JR27.2: Yes, I don't like it, but when we
> inevitably
> > do
> > > > > > another
> > > > > > > > > > KIP-896 to
> > > > > > > > > > > > > remove support for ancient parts of the protocol,
> > it's
> > > > going
> > > > > > to
> > > > > > > > be
> > > > > > > > > > another
> > > > > > > > > > > > > KIP. That's all I meant.
> > > > > > > > > > > > >
> > > > > > > > > > > > > If I understand your proposal correctly compared
> > with the
> > > > > > > > existing
> > > > > > > > > > KIP
> > > > > > > > > > > > > text, it would look like this:
> > > > > > > > > > > > > * Remove RequestHeader v3, and introduce
> > > > ClientInstanceId as
> > > > > > a
> > > > > > > > tagged
> > > > > > > > > > > > > field for versions 2+.
> > > > > > > > > > > > > * Bump the request versions for all RPCs. We'd
> > update the
> > > > > > request
> > > > > > > > > > JSON
> > > > > > > > > > > > > schemas with something like
> > "ClientInstanceIdVersions":
> > > > "X+".
> > > > > > > > This
> > > > > > > > > > would
> > > > > > > > > > > > > mean that the request would only be properly formed
> > if it
> > > > > > had the
> > > > > > > > > > > > > ClientInstanceId present, and would also mean that
> > > > ClientId
> > > > > > > > could be
> > > > > > > > > > null
> > > > > > > > > > > > > for non-initial requests on each connection.
> > > > > > > > > > > > > * We would create ApiVersions v6, simply as a
> matter
> > of
> > > > the
> > > > > > > > bumping
> > > > > > > > > > of
> > > > > > > > > > > > > request versions for all RPCs, but its schema would
> > be
> > > > > > unchanged
> > > > > > > > > > from v5.
> > > > > > > > > > > > > * We would introduce OffsetDelete v1 as the first
> > > > flexible
> > > > > > > > version
> > > > > > > > > > so that
> > > > > > > > > > > > > it uses the v2 request header.
> > > > > > > > > > > > > * We would update PushTelemetry and
> > > > > > GetTelemetrySubscriptions as
> > > > > > > > > > described
> > > > > > > > > > > > > in the KIP and the ClientInstanceId would move to
> the
> > > > request
> > > > > > > > header.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I think that works roughly the same as what we have
> > > > today. I
> > > > > > > > don't
> > > > > > > > > > really
> > > > > > > > > > > > > like the mandatory nature of the tagged field, but
> > then I
> > > > > > don't
> > > > > > > > > > really like
> > > > > > > > > > > > > the way that ApiVersions is pegged on a historical
> > > > request
> > > > > > header
> > > > > > > > > > version.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Do I have this correct? If so, I can update the KIP
> > > > > > accordingly.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > Andrew
> > > > > > > > > > > > >
> > > > > > > > > > > > > On 2026/06/24 23:40:06 Jun Rao via dev wrote:
> > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > JR27.1 What if we want to add non-optional fields
> > to
> > > > the
> > > > > > > > request
> > > > > > > > > > header
> > > > > > > > > > > > > in
> > > > > > > > > > > > > > the future? The choice I see is duplicating the
> > field
> > > > in
> > > > > > the
> > > > > > > > new
> > > > > > > > > > request
> > > > > > > > > > > > > > header and the new ApiVersion request. But it's
> not
> > > > very
> > > > > > clean.
> > > > > > > > > > > > > > JR27.2 Requiring a major version API
> compatibility
> > KIP
> > > > is
> > > > > > also
> > > > > > > > a
> > > > > > > > > > bit
> > > > > > > > > > > > > > awkward.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Here is yet another proposal. We add the
> > > > ClientInstanceId
> > > > > > to
> > > > > > > > the
> > > > > > > > > > request
> > > > > > > > > > > > > > header as a tagged field and also bump up all
> > request
> > > > > > versions.
> > > > > > > > > > This
> > > > > > > > > > > > > avoids
> > > > > > > > > > > > > > the header compatibility issue in SocketServer.
> The
> > > > > > bumped-up
> > > > > > > > > > version
> > > > > > > > > > > > > > signals that the new field is actually required.
> > On the
> > > > > > server
> > > > > > > > > > side, when
> > > > > > > > > > > > > > receiving the new version of a request, we verify
> > that
> > > > the
> > > > > > > > > > > > > ClientInstanceId
> > > > > > > > > > > > > > field exists. If it's not present, we reject the
> > > > request.
> > > > > > This
> > > > > > > > > > will be
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > convention for adding future required fields to
> the
> > > > header.
> > > > > > > > > > Compared to
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > current proposal, this avoids duplicating the
> field
> > > > between
> > > > > > > > request
> > > > > > > > > > > > > header
> > > > > > > > > > > > > > and ApiVersionRequest, and it provides a path for
> > > > > > deprecating
> > > > > > > > the
> > > > > > > > > > older
> > > > > > > > > > > > > > version of the request header. What do you think?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Jun 24, 2026 at 2:15 AM Andrew Schofield
> <
> > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR27: Yes, I enhanced that section of the KIP.
> > > > > > > > > > > > > > > JR27.1: This KIP was unusual because we wanted
> to
> > > > add a
> > > > > > > > concept
> > > > > > > > > > which
> > > > > > > > > > > > > > > existed in the KIP-714 RPCs to the request
> > header,
> > > > > > > > complicating
> > > > > > > > > > the
> > > > > > > > > > > > > > > behavior of those RPCs, AND we wanted to change
> > the
> > > > > > handling
> > > > > > > > of
> > > > > > > > > > client
> > > > > > > > > > > > > ID
> > > > > > > > > > > > > > > without breaking older brokers. If we simply
> > wanted
> > > > to
> > > > > > add a
> > > > > > > > > > brand new
> > > > > > > > > > > > > > > field to the request header, we can do it as a
> > tagged
> > > > > > field
> > > > > > > > in
> > > > > > > > > > request
> > > > > > > > > > > > > > > header versions 2+.
> > > > > > > > > > > > > > > JR27.2: Covered this too. We'd need a major
> > version
> > > > API
> > > > > > > > > > compatibility
> > > > > > > > > > > > > KIP.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR31: Yes. KIP updated.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR32: Yes. This is a minor inconvenience I
> feel.
> > KIP
> > > > > > updated.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR33: I don't see the value of a string
> > comparison
> > > > here.
> > > > > > > > > > Personally,
> > > > > > > > > > > > > I'm
> > > > > > > > > > > > > > > happy with "assume".
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On 2026/06/23 22:52:15 Jun Rao via dev wrote:
> > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > JR27. The code that changed the request
> header
> > > > parsing
> > > > > > was
> > > > > > > > > > > > > introduced in
> > > > > > > > > > > > > > > > 2019 (
> > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> https://urldefense.com/v3/__https://github.com/apache/kafka/pull/7372__;!!Ayb5sqE7!scbWbTEEm2o-Y3MBGi829H2cpMWPRyrF9g2CW3lmRHyRmgBU2MyoRif2mFJpnfmvQ2x7fF4LrAJXdwH86ERR$
> > > > > > > > > > > > > > > ). I agree that fixing it
> > > > > > > > > > > > > > > > now is too late. We should document the path
> > > > forward
> > > > > > for
> > > > > > > > > > ApiVersion.
> > > > > > > > > > > > > > > Could
> > > > > > > > > > > > > > > > we answer at least the following questions in
> > the
> > > > > > > > > > Compatibility,
> > > > > > > > > > > > > > > > Deprecation, and Migration Plan section?
> > > > > > > > > > > > > > > > JR27.1 What happens to ApiVersion if we
> change
> > the
> > > > > > request
> > > > > > > > > > header in
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > future?
> > > > > > > > > > > > > > > > JR27.2 What happens if we ever want to
> > deprecate
> > > > v2 of
> > > > > > the
> > > > > > > > > > request
> > > > > > > > > > > > > > > header?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > JR28. The new MV needs to be covered in the
> > > > > > Compatibility,
> > > > > > > > > > > > > Deprecation,
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > Migration Plan section.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > JR31. "If a connection uses the v3 request
> > header
> > > > in
> > > > > > its
> > > > > > > > first
> > > > > > > > > > > > > request,
> > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > must specify a non-zero client instance ID
> and
> > it
> > > > must
> > > > > > > > specify
> > > > > > > > > > the
> > > > > > > > > > > > > same
> > > > > > > > > > > > > > > > client instance ID for all subsequent
> > requests."
> > > > > > > > > > > > > > > > Do we do the same if the first request is v6
> of
> > > > > > ApiVersion?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > JR32. "For subsequent requests using an
> earlier
> > > > > > version of
> > > > > > > > the
> > > > > > > > > > > > > request
> > > > > > > > > > > > > > > > header, the client sends the client ID". This
> > means
> > > > > > that
> > > > > > > > > > subsequent
> > > > > > > > > > > > > > > > ApiVersion V6 requests will carry the
> non-null
> > > > clientID
> > > > > > > > > > > > > unnecessarily.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > JR33. "After this KIP, the broker will assume
> > that
> > > > the
> > > > > > > > client
> > > > > > > > > > ID
> > > > > > > > > > > > > from the
> > > > > > > > > > > > > > > > initial request applies to all subsequent
> > requests
> > > > on a
> > > > > > > > > > connection,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > will ignore the client ID specified on any
> > > > subsequent
> > > > > > > > > > requests."
> > > > > > > > > > > > > > > > Should the broker verify that the clientId
> from
> > > > > > subsequent
> > > > > > > > > > request
> > > > > > > > > > > > > match
> > > > > > > > > > > > > > > > the first cached one, if not null?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >  Jun
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Tue, Jun 23, 2026 at 6:05 AM Andrew
> > Schofield <
> > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > Thanks for your reply.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > JR27: Unfortunately, I don't think this is
> > > > > > acceptable. We
> > > > > > > > > > would be
> > > > > > > > > > > > > > > saying
> > > > > > > > > > > > > > > > > that AK 4.5 clients can only connect to AK
> > 4.5 or
> > > > > > later
> > > > > > > > > > brokers,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > we'd create patch release for AK 4.0.x to
> AK
> > > > 4.4.x.
> > > > > > so
> > > > > > > > AK 4.5
> > > > > > > > > > > > > clients
> > > > > > > > > > > > > > > could
> > > > > > > > > > > > > > > > > connect to those too. We'd be preventing
> > > > connection
> > > > > > to
> > > > > > > > AK 3.x
> > > > > > > > > > > > > brokers
> > > > > > > > > > > > > > > by AK
> > > > > > > > > > > > > > > > > 4.5 clients. I don't see how we can break
> > > > > > compatibility
> > > > > > > > in a
> > > > > > > > > > minor
> > > > > > > > > > > > > > > release.
> > > > > > > > > > > > > > > > > Here's the existing compatibility table:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> https://urldefense.com/v3/__https://kafka.apache.org/41/getting-started/compatibility/__;!!Ayb5sqE7!ppWU_jI9f7EY9DYwcbiOESSBG2TmPn9CHfLnVM5TaIMwWqHUbUbIiGre1GGKMr-HmelQlyP6ibUSyORCAgte$
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > JR29: OK, makes sense to me.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On 2026/06/22 21:50:43 Jun Rao via dev
> wrote:
> > > > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > JR27. I am not sure I like the approach
> of
> > > > pinning
> > > > > > the
> > > > > > > > > > header to
> > > > > > > > > > > > > v2
> > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > ApiVersionsRequest. This means that in
> the
> > > > future,
> > > > > > each
> > > > > > > > > > change
> > > > > > > > > > > > > to the
> > > > > > > > > > > > > > > > > > request header must be duplicated in the
> > > > request
> > > > > > > > itself.
> > > > > > > > > > Here is
> > > > > > > > > > > > > an
> > > > > > > > > > > > > > > > > > alternative. Note that to detect an
> > unsupported
> > > > > > > > > > > > > ApiVersionRequest, we
> > > > > > > > > > > > > > > > > don't
> > > > > > > > > > > > > > > > > > need to parse the full v2 request header.
> > > > Parsing
> > > > > > the
> > > > > > > > > > first two
> > > > > > > > > > > > > > > fields
> > > > > > > > > > > > > > > > > > ApiKey and ApiVersion is enough. So, we
> > could
> > > > > > patch all
> > > > > > > > > > the 4.x
> > > > > > > > > > > > > > > releases
> > > > > > > > > > > > > > > > > > with a change that short-circuits parsing
> > the
> > > > full
> > > > > > > > request
> > > > > > > > > > header
> > > > > > > > > > > > > > > based
> > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > the first two fields. Then, we recommend
> > > > upgrading
> > > > > > > > from the
> > > > > > > > > > > > > latest
> > > > > > > > > > > > > > > 4.x
> > > > > > > > > > > > > > > > > > releases to future releases. This way, we
> > can
> > > > > > still let
> > > > > > > > > > > > > > > > > ApiVersionsRequest
> > > > > > > > > > > > > > > > > > depend on the request header for current
> > and
> > > > future
> > > > > > > > > > changes.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > JR29. The simplest thing is to upgrade
> the
> > > > KRaft
> > > > > > RPCs
> > > > > > > > too
> > > > > > > > > > to be
> > > > > > > > > > > > > > > > > consistent.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Sat, Jun 20, 2026 at 3:38 AM Andrew
> > > > Schofield <
> > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > > > Thanks for these insightful comments. I
> > did
> > > > > > > > prototype the
> > > > > > > > > > > > > earlier
> > > > > > > > > > > > > > > v2
> > > > > > > > > > > > > > > > > > > request header with tagged fields
> > variant. I
> > > > > > have now
> > > > > > > > > > > > > prototyped
> > > > > > > > > > > > > > > the v3
> > > > > > > > > > > > > > > > > > > request header variant.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > JR27: You were of course entirely
> correct
> > > > that a
> > > > > > new
> > > > > > > > > > version of
> > > > > > > > > > > > > > > > > > > ApiVersions request cannot use a
> request
> > > > header
> > > > > > > > which is
> > > > > > > > > > not
> > > > > > > > > > > > > > > > > > > binary-compatible with what has gone
> > before.
> > > > As a
> > > > > > > > > > result, I
> > > > > > > > > > > > > have
> > > > > > > > > > > > > > > > > introduced
> > > > > > > > > > > > > > > > > > > a new version of ApiVersions request
> > which
> > > > > > includes
> > > > > > > > > > > > > > > ClientInstanceId
> > > > > > > > > > > > > > > > > in the
> > > > > > > > > > > > > > > > > > > request body but continues to use the
> v2
> > > > request
> > > > > > > > header.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > JR28: Yes, we need a new metadata
> > version,
> > > > which
> > > > > > is
> > > > > > > > > > > > > provisionally
> > > > > > > > > > > > > > > > > > > IBP_4_5_IV0. I'll update the KIP with
> the
> > > > final
> > > > > > value
> > > > > > > > > > when it
> > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > assigned.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > JR29: I don't have any strong feelings
> on
> > > > this. I
> > > > > > > > > > suppose for
> > > > > > > > > > > > > each
> > > > > > > > > > > > > > > > > inter
> > > > > > > > > > > > > > > > > > > broker RPC version that is bumped, we
> > need to
> > > > > > > > introduce
> > > > > > > > > > an MV
> > > > > > > > > > > > > > > check. We
> > > > > > > > > > > > > > > > > > > cannot avoid this for RPCs which are
> also
> > > > used by
> > > > > > > > > > clients such
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > Fetch.
> > > > > > > > > > > > > > > > > > > For purely inter-broker RPCs, we could
> > just
> > > > > > exempt
> > > > > > > > them
> > > > > > > > > > from
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > version
> > > > > > > > > > > > > > > > > > > bump. What do you recommend here?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > JR30: Done. INVALID_REQUEST. I did
> > consider
> > > > > > > > permitting
> > > > > > > > > > zero
> > > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > > > instance ID for inter-broker
> connections,
> > > > but I
> > > > > > > > decided
> > > > > > > > > > that I
> > > > > > > > > > > > > > > > > preferred
> > > > > > > > > > > > > > > > > > > not creating another rule.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On 2026/06/17 22:45:07 Andrew Schofield
> > > > wrote:
> > > > > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > JR27: I am familiar with KIP-511 and
> > the
> > > > > > oddness of
> > > > > > > > > > > > > ApiVersions.
> > > > > > > > > > > > > > > You
> > > > > > > > > > > > > > > > > > > make an excellent point. I suspect that
> > > > > > > > > > ApiVersionsRequest will
> > > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > > > to be
> > > > > > > > > > > > > > > > > > > limited to the v2 request header, just
> > as it
> > > > is
> > > > > > > > > > restricted to
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > v0
> > > > > > > > > > > > > > > > > > > response header.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I'll do some experimentation.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On 2026/06/17 17:35:17 Jun Rao via
> dev
> > > > wrote:
> > > > > > > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Thanks for the reply. A few more
> > > > comments.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > JR27. It seems that we have a
> > > > compatibility
> > > > > > issue
> > > > > > > > > > with
> > > > > > > > > > > > > > > > > > > ApiVersionRequest v6
> > > > > > > > > > > > > > > > > > > > > depending on RequestHeader v3. This
> > > > happens
> > > > > > when
> > > > > > > > a
> > > > > > > > > > new
> > > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > issues
> > > > > > > > > > > > > > > > > > > > > ApiVersionRequest v6 to an old
> broker
> > > > (one
> > > > > > that
> > > > > > > > only
> > > > > > > > > > > > > supports
> > > > > > > > > > > > > > > > > > > > > ApiVersionRequest v5). The
> > SocketServer
> > > > in
> > > > > > the
> > > > > > > > > > broker will
> > > > > > > > > > > > > > > first
> > > > > > > > > > > > > > > > > try to
> > > > > > > > > > > > > > > > > > > > > read the request header. It tries
> to
> > > > find the
> > > > > > > > header
> > > > > > > > > > > > > version
> > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > request version. Since the broker
> > doesn't
> > > > > > know
> > > > > > > > > > > > > > > ApiVersionRequest
> > > > > > > > > > > > > > > > > v6, it
> > > > > > > > > > > > > > > > > > > > > uses v2 to parse the request
> header.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > The v2's wire format for the
> request
> > > > header
> > > > > > is:
> > > > > > > > > > ApiKey |
> > > > > > > > > > > > > > > > > ApiVersion |
> > > > > > > > > > > > > > > > > > > > > CorrelationId | ClientId |
> > > > > > tagged-fields-varint
> > > > > > > > > > > > > > > > > > > > > The v3's wire format for the
> request
> > > > header
> > > > > > is:
> > > > > > > > > > ApiKey |
> > > > > > > > > > > > > > > > > ApiVersion |
> > > > > > > > > > > > > > > > > > > > > CorrelationId | ClientId |
> > > > > > ClientInstanceId(16
> > > > > > > > > > bytes) |
> > > > > > > > > > > > > > > > > tagged-fields
> > > > > > > > > > > > > > > > > > > varint
> > > > > > > > > > > > > > > > > > > > > The first 4 fields are identical,
> > > > allowing
> > > > > > the
> > > > > > > > > > broker to
> > > > > > > > > > > > > parse
> > > > > > > > > > > > > > > > > them.
> > > > > > > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > > > > > > broker then tries to read the
> > > > > > > > tagged-fields-varint
> > > > > > > > > > using
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > serialized
> > > > > > > > > > > > > > > > > > > > > bytes intended for
> ClientInstanceId.
> > This
> > > > > > could
> > > > > > > > lead
> > > > > > > > > > to a
> > > > > > > > > > > > > > > parsing
> > > > > > > > > > > > > > > > > > > error and
> > > > > > > > > > > > > > > > > > > > > raise an invalid request error. The
> > > > broker
> > > > > > will
> > > > > > > > > > close the
> > > > > > > > > > > > > > > > > connection
> > > > > > > > > > > > > > > > > > > > > instead of sending a v0 response
> for
> > > > > > > > > > ApiVersionRequest.
> > > > > > > > > > > > > Then
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > > > > > will never be able to detect
> > supported
> > > > API
> > > > > > > > versions
> > > > > > > > > > on the
> > > > > > > > > > > > > old
> > > > > > > > > > > > > > > > > broker.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > The same problem didn't exist when
> > > > > > > > ApiVersionRequest
> > > > > > > > > > > > > changed
> > > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > v1
> > > > > > > > > > > > > > > > > > > > > request header to v2 because the
> wire
> > > > format
> > > > > > for
> > > > > > > > v1
> > > > > > > > > > is a
> > > > > > > > > > > > > > > prefix of
> > > > > > > > > > > > > > > > > v2.
> > > > > > > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > > > > > > problem exists for this KIP because
> > the
> > > > wire
> > > > > > > > format
> > > > > > > > > > of v2
> > > > > > > > > > > > > is no
> > > > > > > > > > > > > > > > > longer
> > > > > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > > > > prefix of v3.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > JR28. Since we are bumping up the
> > > > version of
> > > > > > > > inter
> > > > > > > > > > broker
> > > > > > > > > > > > > > > > > requests, we
> > > > > > > > > > > > > > > > > > > need
> > > > > > > > > > > > > > > > > > > > > to gate them by introducing a new
> MV.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > JR29. Could you specify whether the
> > > > version
> > > > > > for
> > > > > > > > > > KRaft PRCs
> > > > > > > > > > > > > > > will be
> > > > > > > > > > > > > > > > > > > bumped
> > > > > > > > > > > > > > > > > > > > > too?
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > JR30. "If a connection uses the v3
> > > > request
> > > > > > > > header in
> > > > > > > > > > its
> > > > > > > > > > > > > first
> > > > > > > > > > > > > > > > > > > request, it
> > > > > > > > > > > > > > > > > > > > > must specify a non-zero client
> > instance
> > > > ID"
> > > > > > > > > > > > > > > > > > > > > Could we define the broker's
> behavior
> > > > when a
> > > > > > v3
> > > > > > > > > > request
> > > > > > > > > > > > > header
> > > > > > > > > > > > > > > > > > > contains a 0
> > > > > > > > > > > > > > > > > > > > > client instance ID?
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Tue, Jun 16, 2026 at 1:25 AM
> > Andrew
> > > > > > Schofield
> > > > > > > > <
> > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > JR26: Yes, I was considering
> > open-ended
> > > > > > version
> > > > > > > > > > ranges.
> > > > > > > > > > > > > I've
> > > > > > > > > > > > > > > > > updated
> > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > KIP.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Now that we have a new request
> > header
> > > > > > version,
> > > > > > > > I
> > > > > > > > > > think
> > > > > > > > > > > > > it's
> > > > > > > > > > > > > > > safe
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > reintroduce the client ID
> > optimisation.
> > > > > > I've
> > > > > > > > added
> > > > > > > > > > that
> > > > > > > > > > > > > into
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > KIP
> > > > > > > > > > > > > > > > > > > also.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Let me know what you think.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On 2026/06/15 17:46:00 Jun Rao
> via
> > dev
> > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Thanks for the reply. Just a
> > minor
> > > > > > comment.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > JR26. "The keys of the map are
> > either
> > > > > > single
> > > > > > > > > > versions
> > > > > > > > > > > > > like
> > > > > > > > > > > > > > > "0"
> > > > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > > > > closed
> > > > > > > > > > > > > > > > > > > > > > > version ranges like "1-2"."
> > > > > > > > > > > > > > > > > > > > > > > It will be useful to support
> > > > open-ended
> > > > > > > > > > versions. That
> > > > > > > > > > > > > way,
> > > > > > > > > > > > > > > > > "3":
> > > > > > > > > > > > > > > > > > > "3"
> > > > > > > > > > > > > > > > > > > > > > could
> > > > > > > > > > > > > > > > > > > > > > > be "3+": "3". This part won't
> > need to
> > > > > > change
> > > > > > > > in
> > > > > > > > > > the
> > > > > > > > > > > > > future
> > > > > > > > > > > > > > > > > when we
> > > > > > > > > > > > > > > > > > > bump
> > > > > > > > > > > > > > > > > > > > > > up
> > > > > > > > > > > > > > > > > > > > > > > the request version without
> > changing
> > > > the
> > > > > > > > header.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > On Fri, Jun 12, 2026 at 2:12 PM
> > > > Andrew
> > > > > > > > Schofield
> > > > > > > > > > <
> > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > JR25: I agree. I've changed
> to
> > a
> > > > > > > > > > headerVersions map
> > > > > > > > > > > > > in
> > > > > > > > > > > > > > > both
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > request
> > > > > > > > > > > > > > > > > > > > > > > > and response schemas.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Let me know what you think.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > On 2026/06/12 03:39:39 Jun
> Rao
> > via
> > > > dev
> > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Thanks for the updated KIP.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > JR25. I have some concerns
> > about
> > > > > > adding
> > > > > > > > the
> > > > > > > > > > > > > > > > > > > clientInstanceIdVersions
> > > > > > > > > > > > > > > > > > > > > > > > field
> > > > > > > > > > > > > > > > > > > > > > > > > to the schema. First of
> all,
> > it
> > > > only
> > > > > > > > applies
> > > > > > > > > > to
> > > > > > > > > > > > > > > requests,
> > > > > > > > > > > > > > > > > but
> > > > > > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > > > > > > > > > responses. So, it's a bit
> > weird
> > > > to
> > > > > > add
> > > > > > > > it to
> > > > > > > > > > the
> > > > > > > > > > > > > > > general
> > > > > > > > > > > > > > > > > > > schema.
> > > > > > > > > > > > > > > > > > > > > > > > Secondly,
> > > > > > > > > > > > > > > > > > > > > > > > > it's very specific to the
> new
> > > > field
> > > > > > > > added to
> > > > > > > > > > the
> > > > > > > > > > > > > > > request
> > > > > > > > > > > > > > > > > > > header. If
> > > > > > > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > > > > > > change the request header
> > again
> > > > in
> > > > > > the
> > > > > > > > > > future, we
> > > > > > > > > > > > > need
> > > > > > > > > > > > > > > > > another
> > > > > > > > > > > > > > > > > > > way
> > > > > > > > > > > > > > > > > > > > > > to map
> > > > > > > > > > > > > > > > > > > > > > > > > request versions to the new
> > > > header
> > > > > > > > version.
> > > > > > > > > > > > > Ideally, we
> > > > > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > > > > > have a
> > > > > > > > > > > > > > > > > > > > > > > > > generic way to map request
> > > > versions
> > > > > > to
> > > > > > > > all
> > > > > > > > > > future
> > > > > > > > > > > > > > > header
> > > > > > > > > > > > > > > > > > > versions.
> > > > > > > > > > > > > > > > > > > > > > One
> > > > > > > > > > > > > > > > > > > > > > > > > possibility is to
> introduce a
> > > > > > > > headerVersion
> > > > > > > > > > field
> > > > > > > > > > > > > in
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > schema.
> > > > > > > > > > > > > > > > > > > > > > Then,
> > > > > > > > > > > > > > > > > > > > > > > > each
> > > > > > > > > > > > > > > > > > > > > > > > > request/response can use
> this
> > > > field
> > > > > > to
> > > > > > > > map
> > > > > > > > > > its
> > > > > > > > > > > > > > > versions to
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > header
> > > > > > > > > > > > > > > > > > > > > > > > > versions.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jun 9, 2026 at
> > 4:55 AM
> > > > Andrew
> > > > > > > > > > Schofield <
> > > > > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Hi Matthias,
> > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > I have change the version
> > > > property
> > > > > > for
> > > > > > > > > > > > > introducing
> > > > > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > > > > > ID
> > > > > > > > > > > > > > > > > > > > > > > > into
> > > > > > > > > > > > > > > > > > > > > > > > > > the request headers to be
> > > > > > > > > > > > > `clientInstanceIdVersions`
> > > > > > > > > > > > > > > > > which
> > > > > > > > > > > > > > > > > > > is now
> > > > > > > > > > > > > > > > > > > > > > an
> > > > > > > > > > > > > > > > > > > > > > > > > > open-ended range, such as
> > "3+",
> > > > > > more
> > > > > > > > > > closely
> > > > > > > > > > > > > matching
> > > > > > > > > > > > > > > > > what
> > > > > > > > > > > > > > > > > > > we have
> > > > > > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > > > > > > flexible versions.
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > I also added a change to
> > the
> > > > > > > > > > > > > > > > > > > RebalanceConsumer.clientInstanceId
> > > > > > > > > > > > > > > > > > > > > > method
> > > > > > > > > > > > > > > > > > > > > > > > > > introduced in KIP-1306.
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > On 2026/06/03 18:31:06
> > > > "Matthias J.
> > > > > > > > Sax"
> > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks Andrew.
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >  From a KIP-714
> > perspective,
> > > > > > this is
> > > > > > > > a
> > > > > > > > > > great
> > > > > > > > > > > > > > > change,
> > > > > > > > > > > > > > > > > as it
> > > > > > > > > > > > > > > > > > > make
> > > > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > new
> > > > > > > > > > > > > > > > > > > > > > > > > > > RPCs and client/broker
> > > > > > cross-version
> > > > > > > > > > > > > compatibility
> > > > > > > > > > > > > > > > > clean.
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > One question about your
> > > > > > > > `DeleteGroups`
> > > > > > > > > > RPC
> > > > > > > > > > > > > example.
> > > > > > > > > > > > > > > > > Should
> > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > new
> > > > > > > > > > > > > > > > > > > > > > > > > > > version of the RPC say
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > "clientInstanceIdVersion":
> > > > > > "3+",
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > ie, 3+ instead of 3?
> > Similar
> > > > for
> > > > > > > > other
> > > > > > > > > > request,
> > > > > > > > > > > > > > > which
> > > > > > > > > > > > > > > > > > > don't use
> > > > > > > > > > > > > > > > > > > > > > `+`
> > > > > > > > > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> `clientInstanceIdVersion`
> > > > field.
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > -Matthias
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > On 6/2/26 7:42 AM,
> Andrew
> > > > > > Schofield
> > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Following on from the
> > > > > > discussion
> > > > > > > > in the
> > > > > > > > > > > > > > > community,
> > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > difficulty
> > > > > > > > > > > > > > > > > > > > > > > > > > of trying to accommodate
> > the
> > > > client
> > > > > > > > > > instance ID
> > > > > > > > > > > > > in a
> > > > > > > > > > > > > > > > > tagged
> > > > > > > > > > > > > > > > > > > field
> > > > > > > > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > > > > > > > > > acceptable complexity, I
> > have
> > > > made
> > > > > > a
> > > > > > > > > > significant
> > > > > > > > > > > > > > > change
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > the KIP.
> > > > > > > > > > > > > > > > > > > > > > > > Now, it
> > > > > > > > > > > > > > > > > > > > > > > > > > introduces v3 of the
> > request
> > > > header
> > > > > > > > > > containing
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > > > > > ID
> > > > > > > > > > > > > > > > > > > > > > > > as a
> > > > > > > > > > > > > > > > > > > > > > > > > > proper field.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/KAFKA/KIP-1313*3A*Client*instance*ID*in*all*request*headers__;JSsrKysrKys!!Ayb5sqE7!pUZS25PuTKdhiqvTGcwDKbclqpG8dFOzw2Ax9WxVM6Sb09PVQ0gl1i0gjlr2_Krr66agbuVC2qLGgUcg7vrW$
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Please review and let
> > me
> > > > know
> > > > > > what
> > > > > > > > you
> > > > > > > > > > think.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2026/05/28
> 21:51:01
> > > > > > "Matthias J.
> > > > > > > > > > Sax"
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> Thanks Andrew. I
> > agree to
> > > > the
> > > > > > > > issue
> > > > > > > > > > that
> > > > > > > > > > > > > tagged
> > > > > > > > > > > > > > > > > fields
> > > > > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > > > > > > optional.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> Nevertheless, I find
> > the
> > > > > > proposed
> > > > > > > > > > > > > compatibility
> > > > > > > > > > > > > > > > > > > protocol too
> > > > > > > > > > > > > > > > > > > > > > > > complex
> > > > > > > > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> unnecessary, and
> would
> > > > still
> > > > > > > > prefer a
> > > > > > > > > > > > > version
> > > > > > > > > > > > > > > bump
> > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > `GetTelemetrySubscriptionsRequest/Reponse`
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > clean
> > > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > > > > > > > > up. --
> > > > > > > > > > > > > > > > > > > > > > > > For
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > `PushTelemetryRequest` the
> > > > > > > > argument
> > > > > > > > > > from
> > > > > > > > > > > > > above
> > > > > > > > > > > > > > > > > applies,
> > > > > > > > > > > > > > > > > > > so
> > > > > > > > > > > > > > > > > > > > > > > > leaving it
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> untouched is ok.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> I don't see why
> > > > > > > > > > > > > > > `GetTelemetrySubscriptionsRequest`
> > > > > > > > > > > > > > > > > > > would need
> > > > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > > > > > encode
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> the
> `clientInstandId`
> > in
> > > > it's
> > > > > > > > request
> > > > > > > > > > body.
> > > > > > > > > > > > > > > Given
> > > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> `clientInstanceId`
> is
> > a
> > > > random
> > > > > > > > UUID,
> > > > > > > > > > the
> > > > > > > > > > > > > > > returned
> > > > > > > > > > > > > > > > > > > subscription
> > > > > > > > > > > > > > > > > > > > > > > > cannot
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> really depend on it.
> > So
> > > > why
> > > > > > would
> > > > > > > > we
> > > > > > > > > > need to
> > > > > > > > > > > > > > > send
> > > > > > > > > > > > > > > > > it to
> > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > broker?
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> Right now, it's set
> to
> > > > ZERO
> > > > > > only
> > > > > > > > for
> > > > > > > > > > the
> > > > > > > > > > > > > > > purpose to
> > > > > > > > > > > > > > > > > get
> > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > broker to
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> assign a new UUID.
> > But it
> > > > has
> > > > > > > > nothing
> > > > > > > > > > to do
> > > > > > > > > > > > > > > with the
> > > > > > > > > > > > > > > > > > > actual
> > > > > > > > > > > > > > > > > > > > > > "what
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> metrics should I
> send"
> > > > > > question.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> To be fair, KIP-714
> > lists
> > > > > > > > > > > > > `client_instance_id`
> > > > > > > > > > > > > > > as a
> > > > > > > > > > > > > > > > > > > field that
> > > > > > > > > > > > > > > > > > > > > > > > can be
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> used to define a
> > > > subscription.
> > > > > > > > But it
> > > > > > > > > > seems
> > > > > > > > > > > > > > > rather
> > > > > > > > > > > > > > > > > > > useless in
> > > > > > > > > > > > > > > > > > > > > > > > practice
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> to me? I a user
> > defines a
> > > > > > > > > > subscription, they
> > > > > > > > > > > > > > > cannot
> > > > > > > > > > > > > > > > > > > know the
> > > > > > > > > > > > > > > > > > > > > > UUID.
> > > > > > > > > > > > > > > > > > > > > > > > > > Thus,
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> I think we should
> > actually
> > > > > > drop
> > > > > > > > > > supporting
> > > > > > > > > > > > > > > > > > > > > > `client_instance_id`
> > > > > > > > > > > > > > > > > > > > > > > > as a
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> "subscription
> matching
> > > > > > > > parameter"? Of
> > > > > > > > > > > > > course,
> > > > > > > > > > > > > > > there
> > > > > > > > > > > > > > > > > is a
> > > > > > > > > > > > > > > > > > > > > > backward
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> compatibility
> > question,
> > > > but I
> > > > > > > > think
> > > > > > > > > > we can
> > > > > > > > > > > > > > > address
> > > > > > > > > > > > > > > > > > > this: if
> > > > > > > > > > > > > > > > > > > > > > > > brokers
> > > > > > > > > > > > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> upgraded and they
> > have an
> > > > > > existing
> > > > > > > > > > > > > > > > > `client_instance_id`
> > > > > > > > > > > > > > > > > > > based
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> subscription
> defined,
> > they
> > > > > > could
> > > > > > > > > > advertise
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > only
> > > > > > > > > > > > > > > > > > > support
> > > > > > > > > > > > > > > > > > > > > > v0, and
> > > > > > > > > > > > > > > > > > > > > > > > > > they
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> should log a warning
> > that
> > > > this
> > > > > > > > > > feature is
> > > > > > > > > > > > > > > > > deprecated.
> > > > > > > > > > > > > > > > > > > New
> > > > > > > > > > > > > > > > > > > > > > brokers
> > > > > > > > > > > > > > > > > > > > > > > > > > would
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> also not allow to
> use
> > > > > > > > > > `client_instance_id`
> > > > > > > > > > > > > any
> > > > > > > > > > > > > > > > > longer to
> > > > > > > > > > > > > > > > > > > > > > define a
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> subscription.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> Similarly, for
> > > > > > > > > > > > > > > `GetTelemetrySubscriptionsResponse`,
> > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > only
> > > > > > > > > > > > > > > > > > > > > > need
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> `clientInstanceId`
> if
> > the
> > > > > > broker
> > > > > > > > > > computes
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > UUID.
> > > > > > > > > > > > > > > > > But
> > > > > > > > > > > > > > > > > > > if we
> > > > > > > > > > > > > > > > > > > > > > let
> > > > > > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> client compute it,
> > this
> > > > field
> > > > > > is
> > > > > > > > not
> > > > > > > > > > needed
> > > > > > > > > > > > > any
> > > > > > > > > > > > > > > > > longer.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> -Matthias
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >> On 5/28/26 1:21 AM,
> > Andrew
> > > > > > > > Schofield
> > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>> Hi Jun,
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>> Thanks for your
> > response.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>> JR24: I'll update
> > the KIP
> > > > > > > > shortly.
> > > > > > > > > > Here's a
> > > > > > > > > > > > > > > > > summary.
> > > > > > > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > > > > > > > various
> > > > > > > > > > > > > > > > > > > > > > > > > > modern group protocol
> > heartbeat
> > > > > > > > requests
> > > > > > > > > > encode
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > member
> > > > > > > > > > > > > > > > > > > ID as a
> > > > > > > > > > > > > > > > > > > > > > > > string
> > > > > > > > > > > > > > > > > > > > > > > > > > for historical reasons,
> > even
> > > > though
> > > > > > > > it's in
> > > > > > > > > > > > > practice
> > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > UUID.
> > > > > > > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > > > > > > > Apache
> > > > > > > > > > > > > > > > > > > > > > > > > > Kafka Java client happens
> > to
> > > > use
> > > > > > > > > > > > > > > > > > > org.apache.kafka.common.Uuid to
> > > > > > > > > > > > > > > > > > > > > > > > create the
> > > > > > > > > > > > > > > > > > > > > > > > > > member ID and convert it
> > into a
> > > > > > string.
> > > > > > > > > > This
> > > > > > > > > > > > > means
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > when
> > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > > > clientInstanceId is
> > converted
> > > > into
> > > > > > a
> > > > > > > > > > string, its
> > > > > > > > > > > > > > > encoding
> > > > > > > > > > > > > > > > > > > matches
> > > > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > > > member ID and it all
> lines
> > up.
> > > > > > However,
> > > > > > > > > > there are
> > > > > > > > > > > > > > > other
> > > > > > > > > > > > > > > > > ways
> > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > encode
> > > > > > > > > > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > > > > > > > > > UUID into a string and I
> > know
> > > > for a
> > > > > > > > fact
> > > > > > > > > > that the
> > > > > > > > > > > > > > > > > librdkafka
> > > > > > > > > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > > > > > > > > does it
> > > > > > > > > > > > > > > > > > > > > > > > > > differently.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>> Thanks,
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>> Andrew
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>> On 2026/05/27
> > 17:11:25
> > > > Jun
> > > > > > Rao
> > > > > > > > via
> > > > > > > > > > dev
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> Hi, Andrew,
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> Thanks for the
> > reply.
> > > > One
> > > > > > more
> > > > > > > > > > comment.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> JR24. "The
> > alignment of
> > > > > > other
> > > > > > > > > > identifiers
> > > > > > > > > > > > > is
> > > > > > > > > > > > > > > by
> > > > > > > > > > > > > > > > > > > convention
> > > > > > > > > > > > > > > > > > > > > > (and
> > > > > > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > > > Java
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> client will follow
> > the
> > > > > > > > convention)
> > > > > > > > > > rather
> > > > > > > > > > > > > than
> > > > > > > > > > > > > > > > > > > mandate."
> > > > > > > > > > > > > > > > > > > > > > Could
> > > > > > > > > > > > > > > > > > > > > > > > you
> > > > > > > > > > > > > > > > > > > > > > > > > > describe
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> the convention to
> > > > convert a
> > > > > > > > > > > > > clientInstanceId
> > > > > > > > > > > > > > > > > (UUID)
> > > > > > > > > > > > > > > > > > > to a
> > > > > > > > > > > > > > > > > > > > > > > > memberId
> > > > > > > > > > > > > > > > > > > > > > > > > > (String)?
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> Jun
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> On Tue, May 19,
> > 2026 at
> > > > > > 2:36 AM
> > > > > > > > > > Andrew
> > > > > > > > > > > > > > > Schofield <
> > > > > > > > > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> 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 <
> > > > > > > > > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>> 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 <
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>
> > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> 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 <
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>
> > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> 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
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] KIP-1313: Client instance ID in all request headers

[Jun Rao via dev <de...@kafka.apache.org>]

Hi, Andrew,

Thanks for the reply.

JR39. There is still some inconsistency.
For clientInstanceID, we reject any subsequent requests which specify a
different value for the client instance ID. But for clientID, we reject
subsequent requests if the client ID is specified (request header v3 or
later).

Jun


On Thu, Aug 6, 2026 at 12:47 AM Andrew Schofield <sc...@apache.org>
wrote:

> Hi Jun,
> Thanks for your reply.
>
> JR39: KIP description tightened up. That should do the trick.
>
> Thanks,
> Andrew
>
> On 2026/08/05 17:28:34 Jun Rao via dev wrote:
> > Hi, Andrew,
> >
> > Thanks for the reply.
> >
> > JR39. For clientInstanceID, we have: "If a client specifies a reserved
> > client instance ID (zero or one), the request will be rejected with error
> > code INVALID_REQUEST ."
> > For clientId, we have: "After this KIP, the broker will assume that the
> > client ID from the initial request applies to all subsequent requests
> > on a connection,
> > and it will ignore the client ID specified on any subsequent requests."
> > Could we make the behavior consistent between these two?
> >
> > Jun
> >
> >
> > On Tue, Aug 4, 2026 at 1:05 PM Andrew Schofield <sc...@apache.org>
> > wrote:
> >
> > > Hi Jun,
> > > Thanks for the reply.
> > >
> > > JR37: It had escaped me that ClientInstanceId is a tagged field, so
> you're
> > > absolutely right. (I am not an AI.) I'll update the KIP.
> > >
> > > Thanks,
> > > Andrew
> > >
> > > On 2026/08/04 18:24:19 Jun Rao via dev wrote:
> > > > Hi, Andrew,
> > > >
> > > > Thanks for the reply.
> > > >
> > > > JR37. UUID is 16 bytes. If it's omitted in subsequent requests, we
> save
> > > 16
> > > > bytes, right?
> > > >
> > > > Jun
> > > >
> > > >
> > > >
> > > > On Tue, Aug 4, 2026 at 5:47 AM Andrew Schofield <
> schofielaj@apache.org>
> > > > wrote:
> > > >
> > > > > Hi Jun,
> > > > > Thanks for your reply.
> > > > >
> > > > > JR37: Unlike with clientId where space is saved by not
> transmitting it
> > > on
> > > > > every request, there's nothing to be gained by omitting
> > > clientInstanceId on
> > > > > later requests. I prefer to leave it as is.
> > > > >
> > > > > JR38: OK, I've updated those paragraphs in the KIP to exclude the
> > > reserved
> > > > > UUIDs.
> > > > >
> > > > > Thanks,
> > > > > Andrew
> > > > >
> > > > > On 2026/08/03 20:23:39 Jun Rao via dev wrote:
> > > > > > Hi, Andrew,
> > > > > >
> > > > > > Thanks for the reply.
> > > > > >
> > > > > > JR37. Will it be better to require ClientInstanceId only on the
> first
> > > > > > request, to be consistent with clientId?
> > > > > >
> > > > > > JR38. "must specify a non-zero client instance ID". one_uuid is
> also
> > > a
> > > > > > reserved one in the Uuid class. Should we exclude that one too?
> > > > > >
> > > > > > Jun
> > > > > >
> > > > > > On Fri, Jul 31, 2026 at 9:10 AM Andrew Schofield <
> > > schofielaj@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Jun,
> > > > > > > Thanks for the reply and sorry for the delay. Lots of 4.4 stuff
> > > got in
> > > > > the
> > > > > > > way.
> > > > > > >
> > > > > > > JR34: EligibleLeaderReplicasVersion and KRaftVersion also use
> > > > > ApiVersion
> > > > > > > to negotiate the RPC versions. I do not believe we need to
> bump up
> > > > > other
> > > > > > > feature versions as a result of the RPC version bumps in this
> KIP.
> > > > > > >
> > > > > > > JR35: Yes, good catch. In order to handle client ID-based
> quotas
> > > for
> > > > > > > forwarded requests, it will be necessary to populate the
> client ID
> > > in
> > > > > the
> > > > > > > forwarded request header. KIP updated.
> > > > > > >
> > > > > > > JR36: I hadn't considered MV to be a feature version, but I
> > > understand.
> > > > > > > KIP updated.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Andrew
> > > > > > >
> > > > > > > On 2026/06/29 16:23:09 Jun Rao via dev wrote:
> > > > > > > > Hi, Andrew,
> > > > > > > >
> > > > > > > > Thanks for the reply.
> > > > > > > >
> > > > > > > > JR34. Transaction coordinator uses ApiVersion to negotiate
> the
> > > PRC
> > > > > > > > versions. Therefore, if there is no functional change, there
> is
> > > no
> > > > > need
> > > > > > > to
> > > > > > > > bump the TV version. I am not sure about
> > > > > EligibleLeaderReplicasVersion
> > > > > > > > and KRaftVersion.
> > > > > > > > It would be useful to have the experts chime in.
> > > > > > > >
> > > > > > > > JR35. Envelope/forwarding interaction: When a broker
> forwards a
> > > > > client
> > > > > > > > request to the controller via EnvelopeUtils
> > > > > > > (parseForwardedRequestHeader),
> > > > > > > > the inner header may have its clientId optimized to null.
> Some
> > > quota
> > > > > > > > enforcement (e.g. controller mutation) may depend on the
> non-null
> > > > > > > clientId.
> > > > > > > > The per-connection caching occurs on the original
> client↔broker
> > > > > > > connection, not
> > > > > > > > the broker↔controller one. Should the forwarded request
> preserve
> > > the
> > > > > > > > non-null resolved (cached) client.id?
> > > > > > > >
> > > > > > > > JR36. "This KIP does not need to introduce any feature
> version
> > > > > bumps."
> > > > > > > This
> > > > > > > > is not very accurate since MV is a feature version and is
> bumped.
> > > > > > > >
> > > > > > > > Jun
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Jun 26, 2026 at 12:42 AM Andrew Schofield <
> > > > > schofielaj@apache.org
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi Jun,
> > > > > > > > > I've updated the KIP.
> > > > > > > > >
> > > > > > > > > JS34: I don't believe that we need to introduce any new
> feature
> > > > > > > versions
> > > > > > > > > for this KIP. For example, we do not need a new
> ShareVersion
> > > since
> > > > > that
> > > > > > > > > enabled share groups (SV_1) and controls the versioning of
> the
> > > > > records
> > > > > > > on
> > > > > > > > > the internal topics (SV_2). I think the same applies for
> the
> > > > > others. I
> > > > > > > > > understand GroupVersion and StreamsVersion, and I think
> they
> > > > > follow the
> > > > > > > > > same reasoning as ShareVersion. I don't know
> > > TransactionVersion or
> > > > > > > > > EligibleLeaderReplicasVersion, so let me know whether
> those are
> > > > > > > different
> > > > > > > > > in this regard.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Andrew
> > > > > > > > >
> > > > > > > > > On 2026/06/25 21:32:27 Andrew Schofield wrote:
> > > > > > > > > > Hi Jun,
> > > > > > > > > > Thanks for the reply.
> > > > > > > > > >
> > > > > > > > > > JR27: Yes, makes sense. So request header v3 is
> > > binary-compatible
> > > > > > > with
> > > > > > > > > request header v2.
> > > > > > > > > >
> > > > > > > > > > JS34: Yes, I think so.
> > > > > > > > > >
> > > > > > > > > > I'll update the KIP tomorrow morning.
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > Andrew
> > > > > > > > > >
> > > > > > > > > > On 2026/06/25 20:23:57 Jun Rao via dev wrote:
> > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > >
> > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > >
> > > > > > > > > > > JR27. I was thinking of the following, which is
> slightly
> > > > > different
> > > > > > > from
> > > > > > > > > > > what you described.
> > > > > > > > > > > * Bump RequestHeader to v3, and introduce
> ClientInstanceId
> > > as a
> > > > > > > tagged
> > > > > > > > > > > field for versions 3+ and change the semantic of the
> > > existing
> > > > > field
> > > > > > > > > > > clientId (only need to be populated by the first
> request).
> > > > > > > > > > > * Bump the request versions for all RPCs including
> > > ApiVersion
> > > > > and
> > > > > > > map
> > > > > > > > > to
> > > > > > > > > > > the new version to use v3 of RequestHeader.
> > > > > > > > > > > * On the server side, when a new request version is
> seen,
> > > we
> > > > > > > enforce
> > > > > > > > > the
> > > > > > > > > > > presence of ClientInstanceId and reject the request if
> it
> > > is
> > > > > > > missing.
> > > > > > > > > > > Essentially, treat it as a required field. We also
> cache
> > > the
> > > > > > > clientId
> > > > > > > > > from
> > > > > > > > > > > the first request and ignore it from subsequent ones.
> > > > > > > > > > > * We would introduce OffsetDelete v1 as the first
> flexible
> > > > > version
> > > > > > > so
> > > > > > > > > that
> > > > > > > > > > > it uses the v3 request header.
> > > > > > > > > > > * We would update PushTelemetry and
> > > GetTelemetrySubscriptions
> > > > > as
> > > > > > > > > described
> > > > > > > > > > > in the KIP and the ClientInstanceId would move to the
> > > request
> > > > > > > header.
> > > > > > > > > > >
> > > > > > > > > > > In the future, if we want to add a new truly optional
> > > field to
> > > > > > > > > > > RequestHeader, we can continue adding it as a tagged
> field
> > > > > without
> > > > > > > > > bumping
> > > > > > > > > > > up the request version. To add a required field, we
> will
> > > add
> > > > > it as
> > > > > > > a
> > > > > > > > > tagged
> > > > > > > > > > > field but force a version bump to all requests.
> > > > > > > > > > >
> > > > > > > > > > > The benefit of this approach is that (1) it's
> compatible
> > > with
> > > > > the
> > > > > > > > > format of
> > > > > > > > > > > the old request header; (2) it avoids duplicating new
> > > fields;
> > > > > and
> > > > > > > (3)
> > > > > > > > > there
> > > > > > > > > > > is no constraint on deprecating the old request header.
> > > It's
> > > > > > > slightly
> > > > > > > > > weird
> > > > > > > > > > > to bump up the version when adding a tagged field. But
> it
> > > still
> > > > > > > seems
> > > > > > > > > > > better than the alternatives.
> > > > > > > > > > >
> > > > > > > > > > > JR34. Since we now have different feature versions
> gating
> > > > > different
> > > > > > > > > RPCs,
> > > > > > > > > > > should we bump up GV, TV, etc., too?
> > > > > > > > > > >
> > > > > > > > > > > Jun
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Jun 25, 2026 at 10:37 AM Andrew Schofield <
> > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > >
> > > > > > > > > > > > JR27.1: What if we want to add non-optional fields
> to the
> > > > > request
> > > > > > > > > header
> > > > > > > > > > > > in the future? I think that such fields would be by
> > > > > definition
> > > > > > > future
> > > > > > > > > > > > fields which would not be understood by existing
> > > brokers. For
> > > > > > > > > serialization
> > > > > > > > > > > > reasons, I think we would use version 2+ tagged
> fields
> > > and
> > > > > the
> > > > > > > > > requirement
> > > > > > > > > > > > for non-optionality would be enforced by code, rather
> > > than
> > > > > by the
> > > > > > > > > protocol
> > > > > > > > > > > > schema. This avoids the field duplication.
> > > > > > > > > > > >
> > > > > > > > > > > > JR27.2: Yes, I don't like it, but when we inevitably
> do
> > > > > another
> > > > > > > > > KIP-896 to
> > > > > > > > > > > > remove support for ancient parts of the protocol,
> it's
> > > going
> > > > > to
> > > > > > > be
> > > > > > > > > another
> > > > > > > > > > > > KIP. That's all I meant.
> > > > > > > > > > > >
> > > > > > > > > > > > If I understand your proposal correctly compared
> with the
> > > > > > > existing
> > > > > > > > > KIP
> > > > > > > > > > > > text, it would look like this:
> > > > > > > > > > > > * Remove RequestHeader v3, and introduce
> > > ClientInstanceId as
> > > > > a
> > > > > > > tagged
> > > > > > > > > > > > field for versions 2+.
> > > > > > > > > > > > * Bump the request versions for all RPCs. We'd
> update the
> > > > > request
> > > > > > > > > JSON
> > > > > > > > > > > > schemas with something like
> "ClientInstanceIdVersions":
> > > "X+".
> > > > > > > This
> > > > > > > > > would
> > > > > > > > > > > > mean that the request would only be properly formed
> if it
> > > > > had the
> > > > > > > > > > > > ClientInstanceId present, and would also mean that
> > > ClientId
> > > > > > > could be
> > > > > > > > > null
> > > > > > > > > > > > for non-initial requests on each connection.
> > > > > > > > > > > > * We would create ApiVersions v6, simply as a matter
> of
> > > the
> > > > > > > bumping
> > > > > > > > > of
> > > > > > > > > > > > request versions for all RPCs, but its schema would
> be
> > > > > unchanged
> > > > > > > > > from v5.
> > > > > > > > > > > > * We would introduce OffsetDelete v1 as the first
> > > flexible
> > > > > > > version
> > > > > > > > > so that
> > > > > > > > > > > > it uses the v2 request header.
> > > > > > > > > > > > * We would update PushTelemetry and
> > > > > GetTelemetrySubscriptions as
> > > > > > > > > described
> > > > > > > > > > > > in the KIP and the ClientInstanceId would move to the
> > > request
> > > > > > > header.
> > > > > > > > > > > >
> > > > > > > > > > > > I think that works roughly the same as what we have
> > > today. I
> > > > > > > don't
> > > > > > > > > really
> > > > > > > > > > > > like the mandatory nature of the tagged field, but
> then I
> > > > > don't
> > > > > > > > > really like
> > > > > > > > > > > > the way that ApiVersions is pegged on a historical
> > > request
> > > > > header
> > > > > > > > > version.
> > > > > > > > > > > >
> > > > > > > > > > > > Do I have this correct? If so, I can update the KIP
> > > > > accordingly.
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks,
> > > > > > > > > > > > Andrew
> > > > > > > > > > > >
> > > > > > > > > > > > On 2026/06/24 23:40:06 Jun Rao via dev wrote:
> > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > > >
> > > > > > > > > > > > > JR27.1 What if we want to add non-optional fields
> to
> > > the
> > > > > > > request
> > > > > > > > > header
> > > > > > > > > > > > in
> > > > > > > > > > > > > the future? The choice I see is duplicating the
> field
> > > in
> > > > > the
> > > > > > > new
> > > > > > > > > request
> > > > > > > > > > > > > header and the new ApiVersion request. But it's not
> > > very
> > > > > clean.
> > > > > > > > > > > > > JR27.2 Requiring a major version API compatibility
> KIP
> > > is
> > > > > also
> > > > > > > a
> > > > > > > > > bit
> > > > > > > > > > > > > awkward.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Here is yet another proposal. We add the
> > > ClientInstanceId
> > > > > to
> > > > > > > the
> > > > > > > > > request
> > > > > > > > > > > > > header as a tagged field and also bump up all
> request
> > > > > versions.
> > > > > > > > > This
> > > > > > > > > > > > avoids
> > > > > > > > > > > > > the header compatibility issue in SocketServer. The
> > > > > bumped-up
> > > > > > > > > version
> > > > > > > > > > > > > signals that the new field is actually required.
> On the
> > > > > server
> > > > > > > > > side, when
> > > > > > > > > > > > > receiving the new version of a request, we verify
> that
> > > the
> > > > > > > > > > > > ClientInstanceId
> > > > > > > > > > > > > field exists. If it's not present, we reject the
> > > request.
> > > > > This
> > > > > > > > > will be
> > > > > > > > > > > > the
> > > > > > > > > > > > > convention for adding future required fields to the
> > > header.
> > > > > > > > > Compared to
> > > > > > > > > > > > the
> > > > > > > > > > > > > current proposal, this avoids duplicating the field
> > > between
> > > > > > > request
> > > > > > > > > > > > header
> > > > > > > > > > > > > and ApiVersionRequest, and it provides a path for
> > > > > deprecating
> > > > > > > the
> > > > > > > > > older
> > > > > > > > > > > > > version of the request header. What do you think?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Jun
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Jun 24, 2026 at 2:15 AM Andrew Schofield <
> > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > JR27: Yes, I enhanced that section of the KIP.
> > > > > > > > > > > > > > JR27.1: This KIP was unusual because we wanted to
> > > add a
> > > > > > > concept
> > > > > > > > > which
> > > > > > > > > > > > > > existed in the KIP-714 RPCs to the request
> header,
> > > > > > > complicating
> > > > > > > > > the
> > > > > > > > > > > > > > behavior of those RPCs, AND we wanted to change
> the
> > > > > handling
> > > > > > > of
> > > > > > > > > client
> > > > > > > > > > > > ID
> > > > > > > > > > > > > > without breaking older brokers. If we simply
> wanted
> > > to
> > > > > add a
> > > > > > > > > brand new
> > > > > > > > > > > > > > field to the request header, we can do it as a
> tagged
> > > > > field
> > > > > > > in
> > > > > > > > > request
> > > > > > > > > > > > > > header versions 2+.
> > > > > > > > > > > > > > JR27.2: Covered this too. We'd need a major
> version
> > > API
> > > > > > > > > compatibility
> > > > > > > > > > > > KIP.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > JR31: Yes. KIP updated.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > JR32: Yes. This is a minor inconvenience I feel.
> KIP
> > > > > updated.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > JR33: I don't see the value of a string
> comparison
> > > here.
> > > > > > > > > Personally,
> > > > > > > > > > > > I'm
> > > > > > > > > > > > > > happy with "assume".
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On 2026/06/23 22:52:15 Jun Rao via dev wrote:
> > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR27. The code that changed the request header
> > > parsing
> > > > > was
> > > > > > > > > > > > introduced in
> > > > > > > > > > > > > > > 2019 (
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://urldefense.com/v3/__https://github.com/apache/kafka/pull/7372__;!!Ayb5sqE7!scbWbTEEm2o-Y3MBGi829H2cpMWPRyrF9g2CW3lmRHyRmgBU2MyoRif2mFJpnfmvQ2x7fF4LrAJXdwH86ERR$
> > > > > > > > > > > > > > ). I agree that fixing it
> > > > > > > > > > > > > > > now is too late. We should document the path
> > > forward
> > > > > for
> > > > > > > > > ApiVersion.
> > > > > > > > > > > > > > Could
> > > > > > > > > > > > > > > we answer at least the following questions in
> the
> > > > > > > > > Compatibility,
> > > > > > > > > > > > > > > Deprecation, and Migration Plan section?
> > > > > > > > > > > > > > > JR27.1 What happens to ApiVersion if we change
> the
> > > > > request
> > > > > > > > > header in
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > future?
> > > > > > > > > > > > > > > JR27.2 What happens if we ever want to
> deprecate
> > > v2 of
> > > > > the
> > > > > > > > > request
> > > > > > > > > > > > > > header?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR28. The new MV needs to be covered in the
> > > > > Compatibility,
> > > > > > > > > > > > Deprecation,
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > Migration Plan section.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR31. "If a connection uses the v3 request
> header
> > > in
> > > > > its
> > > > > > > first
> > > > > > > > > > > > request,
> > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > must specify a non-zero client instance ID and
> it
> > > must
> > > > > > > specify
> > > > > > > > > the
> > > > > > > > > > > > same
> > > > > > > > > > > > > > > client instance ID for all subsequent
> requests."
> > > > > > > > > > > > > > > Do we do the same if the first request is v6 of
> > > > > ApiVersion?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR32. "For subsequent requests using an earlier
> > > > > version of
> > > > > > > the
> > > > > > > > > > > > request
> > > > > > > > > > > > > > > header, the client sends the client ID". This
> means
> > > > > that
> > > > > > > > > subsequent
> > > > > > > > > > > > > > > ApiVersion V6 requests will carry the non-null
> > > clientID
> > > > > > > > > > > > unnecessarily.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR33. "After this KIP, the broker will assume
> that
> > > the
> > > > > > > client
> > > > > > > > > ID
> > > > > > > > > > > > from the
> > > > > > > > > > > > > > > initial request applies to all subsequent
> requests
> > > on a
> > > > > > > > > connection,
> > > > > > > > > > > > and
> > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > will ignore the client ID specified on any
> > > subsequent
> > > > > > > > > requests."
> > > > > > > > > > > > > > > Should the broker verify that the clientId from
> > > > > subsequent
> > > > > > > > > request
> > > > > > > > > > > > match
> > > > > > > > > > > > > > > the first cached one, if not null?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >  Jun
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Tue, Jun 23, 2026 at 6:05 AM Andrew
> Schofield <
> > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > Thanks for your reply.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > JR27: Unfortunately, I don't think this is
> > > > > acceptable. We
> > > > > > > > > would be
> > > > > > > > > > > > > > saying
> > > > > > > > > > > > > > > > that AK 4.5 clients can only connect to AK
> 4.5 or
> > > > > later
> > > > > > > > > brokers,
> > > > > > > > > > > > and
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > we'd create patch release for AK 4.0.x to AK
> > > 4.4.x.
> > > > > so
> > > > > > > AK 4.5
> > > > > > > > > > > > clients
> > > > > > > > > > > > > > could
> > > > > > > > > > > > > > > > connect to those too. We'd be preventing
> > > connection
> > > > > to
> > > > > > > AK 3.x
> > > > > > > > > > > > brokers
> > > > > > > > > > > > > > by AK
> > > > > > > > > > > > > > > > 4.5 clients. I don't see how we can break
> > > > > compatibility
> > > > > > > in a
> > > > > > > > > minor
> > > > > > > > > > > > > > release.
> > > > > > > > > > > > > > > > Here's the existing compatibility table:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://urldefense.com/v3/__https://kafka.apache.org/41/getting-started/compatibility/__;!!Ayb5sqE7!ppWU_jI9f7EY9DYwcbiOESSBG2TmPn9CHfLnVM5TaIMwWqHUbUbIiGre1GGKMr-HmelQlyP6ibUSyORCAgte$
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > JR29: OK, makes sense to me.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On 2026/06/22 21:50:43 Jun Rao via dev wrote:
> > > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > JR27. I am not sure I like the approach of
> > > pinning
> > > > > the
> > > > > > > > > header to
> > > > > > > > > > > > v2
> > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > ApiVersionsRequest. This means that in the
> > > future,
> > > > > each
> > > > > > > > > change
> > > > > > > > > > > > to the
> > > > > > > > > > > > > > > > > request header must be duplicated in the
> > > request
> > > > > > > itself.
> > > > > > > > > Here is
> > > > > > > > > > > > an
> > > > > > > > > > > > > > > > > alternative. Note that to detect an
> unsupported
> > > > > > > > > > > > ApiVersionRequest, we
> > > > > > > > > > > > > > > > don't
> > > > > > > > > > > > > > > > > need to parse the full v2 request header.
> > > Parsing
> > > > > the
> > > > > > > > > first two
> > > > > > > > > > > > > > fields
> > > > > > > > > > > > > > > > > ApiKey and ApiVersion is enough. So, we
> could
> > > > > patch all
> > > > > > > > > the 4.x
> > > > > > > > > > > > > > releases
> > > > > > > > > > > > > > > > > with a change that short-circuits parsing
> the
> > > full
> > > > > > > request
> > > > > > > > > header
> > > > > > > > > > > > > > based
> > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > the first two fields. Then, we recommend
> > > upgrading
> > > > > > > from the
> > > > > > > > > > > > latest
> > > > > > > > > > > > > > 4.x
> > > > > > > > > > > > > > > > > releases to future releases. This way, we
> can
> > > > > still let
> > > > > > > > > > > > > > > > ApiVersionsRequest
> > > > > > > > > > > > > > > > > depend on the request header for current
> and
> > > future
> > > > > > > > > changes.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > JR29. The simplest thing is to upgrade the
> > > KRaft
> > > > > RPCs
> > > > > > > too
> > > > > > > > > to be
> > > > > > > > > > > > > > > > consistent.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Sat, Jun 20, 2026 at 3:38 AM Andrew
> > > Schofield <
> > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > > Thanks for these insightful comments. I
> did
> > > > > > > prototype the
> > > > > > > > > > > > earlier
> > > > > > > > > > > > > > v2
> > > > > > > > > > > > > > > > > > request header with tagged fields
> variant. I
> > > > > have now
> > > > > > > > > > > > prototyped
> > > > > > > > > > > > > > the v3
> > > > > > > > > > > > > > > > > > request header variant.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > JR27: You were of course entirely correct
> > > that a
> > > > > new
> > > > > > > > > version of
> > > > > > > > > > > > > > > > > > ApiVersions request cannot use a request
> > > header
> > > > > > > which is
> > > > > > > > > not
> > > > > > > > > > > > > > > > > > binary-compatible with what has gone
> before.
> > > As a
> > > > > > > > > result, I
> > > > > > > > > > > > have
> > > > > > > > > > > > > > > > introduced
> > > > > > > > > > > > > > > > > > a new version of ApiVersions request
> which
> > > > > includes
> > > > > > > > > > > > > > ClientInstanceId
> > > > > > > > > > > > > > > > in the
> > > > > > > > > > > > > > > > > > request body but continues to use the v2
> > > request
> > > > > > > header.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > JR28: Yes, we need a new metadata
> version,
> > > which
> > > > > is
> > > > > > > > > > > > provisionally
> > > > > > > > > > > > > > > > > > IBP_4_5_IV0. I'll update the KIP with the
> > > final
> > > > > value
> > > > > > > > > when it
> > > > > > > > > > > > is
> > > > > > > > > > > > > > > > assigned.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > JR29: I don't have any strong feelings on
> > > this. I
> > > > > > > > > suppose for
> > > > > > > > > > > > each
> > > > > > > > > > > > > > > > inter
> > > > > > > > > > > > > > > > > > broker RPC version that is bumped, we
> need to
> > > > > > > introduce
> > > > > > > > > an MV
> > > > > > > > > > > > > > check. We
> > > > > > > > > > > > > > > > > > cannot avoid this for RPCs which are also
> > > used by
> > > > > > > > > clients such
> > > > > > > > > > > > as
> > > > > > > > > > > > > > > > Fetch.
> > > > > > > > > > > > > > > > > > For purely inter-broker RPCs, we could
> just
> > > > > exempt
> > > > > > > them
> > > > > > > > > from
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > version
> > > > > > > > > > > > > > > > > > bump. What do you recommend here?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > JR30: Done. INVALID_REQUEST. I did
> consider
> > > > > > > permitting
> > > > > > > > > zero
> > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > > instance ID for inter-broker connections,
> > > but I
> > > > > > > decided
> > > > > > > > > that I
> > > > > > > > > > > > > > > > preferred
> > > > > > > > > > > > > > > > > > not creating another rule.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On 2026/06/17 22:45:07 Andrew Schofield
> > > wrote:
> > > > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > JR27: I am familiar with KIP-511 and
> the
> > > > > oddness of
> > > > > > > > > > > > ApiVersions.
> > > > > > > > > > > > > > You
> > > > > > > > > > > > > > > > > > make an excellent point. I suspect that
> > > > > > > > > ApiVersionsRequest will
> > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > > to be
> > > > > > > > > > > > > > > > > > limited to the v2 request header, just
> as it
> > > is
> > > > > > > > > restricted to
> > > > > > > > > > > > the
> > > > > > > > > > > > > > v0
> > > > > > > > > > > > > > > > > > response header.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I'll do some experimentation.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On 2026/06/17 17:35:17 Jun Rao via dev
> > > wrote:
> > > > > > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Thanks for the reply. A few more
> > > comments.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > JR27. It seems that we have a
> > > compatibility
> > > > > issue
> > > > > > > > > with
> > > > > > > > > > > > > > > > > > ApiVersionRequest v6
> > > > > > > > > > > > > > > > > > > > depending on RequestHeader v3. This
> > > happens
> > > > > when
> > > > > > > a
> > > > > > > > > new
> > > > > > > > > > > > client
> > > > > > > > > > > > > > > > issues
> > > > > > > > > > > > > > > > > > > > ApiVersionRequest v6 to an old broker
> > > (one
> > > > > that
> > > > > > > only
> > > > > > > > > > > > supports
> > > > > > > > > > > > > > > > > > > > ApiVersionRequest v5). The
> SocketServer
> > > in
> > > > > the
> > > > > > > > > broker will
> > > > > > > > > > > > > > first
> > > > > > > > > > > > > > > > try to
> > > > > > > > > > > > > > > > > > > > read the request header. It tries to
> > > find the
> > > > > > > header
> > > > > > > > > > > > version
> > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > request version. Since the broker
> doesn't
> > > > > know
> > > > > > > > > > > > > > ApiVersionRequest
> > > > > > > > > > > > > > > > v6, it
> > > > > > > > > > > > > > > > > > > > uses v2 to parse the request header.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > The v2's wire format for the request
> > > header
> > > > > is:
> > > > > > > > > ApiKey |
> > > > > > > > > > > > > > > > ApiVersion |
> > > > > > > > > > > > > > > > > > > > CorrelationId | ClientId |
> > > > > tagged-fields-varint
> > > > > > > > > > > > > > > > > > > > The v3's wire format for the request
> > > header
> > > > > is:
> > > > > > > > > ApiKey |
> > > > > > > > > > > > > > > > ApiVersion |
> > > > > > > > > > > > > > > > > > > > CorrelationId | ClientId |
> > > > > ClientInstanceId(16
> > > > > > > > > bytes) |
> > > > > > > > > > > > > > > > tagged-fields
> > > > > > > > > > > > > > > > > > varint
> > > > > > > > > > > > > > > > > > > > The first 4 fields are identical,
> > > allowing
> > > > > the
> > > > > > > > > broker to
> > > > > > > > > > > > parse
> > > > > > > > > > > > > > > > them.
> > > > > > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > > > > > broker then tries to read the
> > > > > > > tagged-fields-varint
> > > > > > > > > using
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > serialized
> > > > > > > > > > > > > > > > > > > > bytes intended for ClientInstanceId.
> This
> > > > > could
> > > > > > > lead
> > > > > > > > > to a
> > > > > > > > > > > > > > parsing
> > > > > > > > > > > > > > > > > > error and
> > > > > > > > > > > > > > > > > > > > raise an invalid request error. The
> > > broker
> > > > > will
> > > > > > > > > close the
> > > > > > > > > > > > > > > > connection
> > > > > > > > > > > > > > > > > > > > instead of sending a v0 response for
> > > > > > > > > ApiVersionRequest.
> > > > > > > > > > > > Then
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > > > > will never be able to detect
> supported
> > > API
> > > > > > > versions
> > > > > > > > > on the
> > > > > > > > > > > > old
> > > > > > > > > > > > > > > > broker.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > The same problem didn't exist when
> > > > > > > ApiVersionRequest
> > > > > > > > > > > > changed
> > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > v1
> > > > > > > > > > > > > > > > > > > > request header to v2 because the wire
> > > format
> > > > > for
> > > > > > > v1
> > > > > > > > > is a
> > > > > > > > > > > > > > prefix of
> > > > > > > > > > > > > > > > v2.
> > > > > > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > > > > > problem exists for this KIP because
> the
> > > wire
> > > > > > > format
> > > > > > > > > of v2
> > > > > > > > > > > > is no
> > > > > > > > > > > > > > > > longer
> > > > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > > > prefix of v3.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > JR28. Since we are bumping up the
> > > version of
> > > > > > > inter
> > > > > > > > > broker
> > > > > > > > > > > > > > > > requests, we
> > > > > > > > > > > > > > > > > > need
> > > > > > > > > > > > > > > > > > > > to gate them by introducing a new MV.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > JR29. Could you specify whether the
> > > version
> > > > > for
> > > > > > > > > KRaft PRCs
> > > > > > > > > > > > > > will be
> > > > > > > > > > > > > > > > > > bumped
> > > > > > > > > > > > > > > > > > > > too?
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > JR30. "If a connection uses the v3
> > > request
> > > > > > > header in
> > > > > > > > > its
> > > > > > > > > > > > first
> > > > > > > > > > > > > > > > > > request, it
> > > > > > > > > > > > > > > > > > > > must specify a non-zero client
> instance
> > > ID"
> > > > > > > > > > > > > > > > > > > > Could we define the broker's behavior
> > > when a
> > > > > v3
> > > > > > > > > request
> > > > > > > > > > > > header
> > > > > > > > > > > > > > > > > > contains a 0
> > > > > > > > > > > > > > > > > > > > client instance ID?
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Tue, Jun 16, 2026 at 1:25 AM
> Andrew
> > > > > Schofield
> > > > > > > <
> > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > JR26: Yes, I was considering
> open-ended
> > > > > version
> > > > > > > > > ranges.
> > > > > > > > > > > > I've
> > > > > > > > > > > > > > > > updated
> > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > KIP.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Now that we have a new request
> header
> > > > > version,
> > > > > > > I
> > > > > > > > > think
> > > > > > > > > > > > it's
> > > > > > > > > > > > > > safe
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > reintroduce the client ID
> optimisation.
> > > > > I've
> > > > > > > added
> > > > > > > > > that
> > > > > > > > > > > > into
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > KIP
> > > > > > > > > > > > > > > > > > also.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Let me know what you think.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On 2026/06/15 17:46:00 Jun Rao via
> dev
> > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Thanks for the reply. Just a
> minor
> > > > > comment.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > JR26. "The keys of the map are
> either
> > > > > single
> > > > > > > > > versions
> > > > > > > > > > > > like
> > > > > > > > > > > > > > "0"
> > > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > > > closed
> > > > > > > > > > > > > > > > > > > > > > version ranges like "1-2"."
> > > > > > > > > > > > > > > > > > > > > > It will be useful to support
> > > open-ended
> > > > > > > > > versions. That
> > > > > > > > > > > > way,
> > > > > > > > > > > > > > > > "3":
> > > > > > > > > > > > > > > > > > "3"
> > > > > > > > > > > > > > > > > > > > > could
> > > > > > > > > > > > > > > > > > > > > > be "3+": "3". This part won't
> need to
> > > > > change
> > > > > > > in
> > > > > > > > > the
> > > > > > > > > > > > future
> > > > > > > > > > > > > > > > when we
> > > > > > > > > > > > > > > > > > bump
> > > > > > > > > > > > > > > > > > > > > up
> > > > > > > > > > > > > > > > > > > > > > the request version without
> changing
> > > the
> > > > > > > header.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Fri, Jun 12, 2026 at 2:12 PM
> > > Andrew
> > > > > > > Schofield
> > > > > > > > > <
> > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > JR25: I agree. I've changed to
> a
> > > > > > > > > headerVersions map
> > > > > > > > > > > > in
> > > > > > > > > > > > > > both
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > request
> > > > > > > > > > > > > > > > > > > > > > > and response schemas.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Let me know what you think.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > On 2026/06/12 03:39:39 Jun Rao
> via
> > > dev
> > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Thanks for the updated KIP.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > JR25. I have some concerns
> about
> > > > > adding
> > > > > > > the
> > > > > > > > > > > > > > > > > > clientInstanceIdVersions
> > > > > > > > > > > > > > > > > > > > > > > field
> > > > > > > > > > > > > > > > > > > > > > > > to the schema. First of all,
> it
> > > only
> > > > > > > applies
> > > > > > > > > to
> > > > > > > > > > > > > > requests,
> > > > > > > > > > > > > > > > but
> > > > > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > > > > > > > > responses. So, it's a bit
> weird
> > > to
> > > > > add
> > > > > > > it to
> > > > > > > > > the
> > > > > > > > > > > > > > general
> > > > > > > > > > > > > > > > > > schema.
> > > > > > > > > > > > > > > > > > > > > > > Secondly,
> > > > > > > > > > > > > > > > > > > > > > > > it's very specific to the new
> > > field
> > > > > > > added to
> > > > > > > > > the
> > > > > > > > > > > > > > request
> > > > > > > > > > > > > > > > > > header. If
> > > > > > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > > > > > change the request header
> again
> > > in
> > > > > the
> > > > > > > > > future, we
> > > > > > > > > > > > need
> > > > > > > > > > > > > > > > another
> > > > > > > > > > > > > > > > > > way
> > > > > > > > > > > > > > > > > > > > > to map
> > > > > > > > > > > > > > > > > > > > > > > > request versions to the new
> > > header
> > > > > > > version.
> > > > > > > > > > > > Ideally, we
> > > > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > > > > have a
> > > > > > > > > > > > > > > > > > > > > > > > generic way to map request
> > > versions
> > > > > to
> > > > > > > all
> > > > > > > > > future
> > > > > > > > > > > > > > header
> > > > > > > > > > > > > > > > > > versions.
> > > > > > > > > > > > > > > > > > > > > One
> > > > > > > > > > > > > > > > > > > > > > > > possibility is to introduce a
> > > > > > > headerVersion
> > > > > > > > > field
> > > > > > > > > > > > in
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > schema.
> > > > > > > > > > > > > > > > > > > > > Then,
> > > > > > > > > > > > > > > > > > > > > > > each
> > > > > > > > > > > > > > > > > > > > > > > > request/response can use this
> > > field
> > > > > to
> > > > > > > map
> > > > > > > > > its
> > > > > > > > > > > > > > versions to
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > header
> > > > > > > > > > > > > > > > > > > > > > > > versions.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jun 9, 2026 at
> 4:55 AM
> > > Andrew
> > > > > > > > > Schofield <
> > > > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Hi Matthias,
> > > > > > > > > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > I have change the version
> > > property
> > > > > for
> > > > > > > > > > > > introducing
> > > > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > > > > ID
> > > > > > > > > > > > > > > > > > > > > > > into
> > > > > > > > > > > > > > > > > > > > > > > > > the request headers to be
> > > > > > > > > > > > `clientInstanceIdVersions`
> > > > > > > > > > > > > > > > which
> > > > > > > > > > > > > > > > > > is now
> > > > > > > > > > > > > > > > > > > > > an
> > > > > > > > > > > > > > > > > > > > > > > > > open-ended range, such as
> "3+",
> > > > > more
> > > > > > > > > closely
> > > > > > > > > > > > matching
> > > > > > > > > > > > > > > > what
> > > > > > > > > > > > > > > > > > we have
> > > > > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > > > > > flexible versions.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > I also added a change to
> the
> > > > > > > > > > > > > > > > > > RebalanceConsumer.clientInstanceId
> > > > > > > > > > > > > > > > > > > > > method
> > > > > > > > > > > > > > > > > > > > > > > > > introduced in KIP-1306.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > On 2026/06/03 18:31:06
> > > "Matthias J.
> > > > > > > Sax"
> > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > Thanks Andrew.
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >  From a KIP-714
> perspective,
> > > > > this is
> > > > > > > a
> > > > > > > > > great
> > > > > > > > > > > > > > change,
> > > > > > > > > > > > > > > > as it
> > > > > > > > > > > > > > > > > > make
> > > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > new
> > > > > > > > > > > > > > > > > > > > > > > > > > RPCs and client/broker
> > > > > cross-version
> > > > > > > > > > > > compatibility
> > > > > > > > > > > > > > > > clean.
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > One question about your
> > > > > > > `DeleteGroups`
> > > > > > > > > RPC
> > > > > > > > > > > > example.
> > > > > > > > > > > > > > > > Should
> > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > new
> > > > > > > > > > > > > > > > > > > > > > > > > > version of the RPC say
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> "clientInstanceIdVersion":
> > > > > "3+",
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > ie, 3+ instead of 3?
> Similar
> > > for
> > > > > > > other
> > > > > > > > > request,
> > > > > > > > > > > > > > which
> > > > > > > > > > > > > > > > > > don't use
> > > > > > > > > > > > > > > > > > > > > `+`
> > > > > > > > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > > > > > > `clientInstanceIdVersion`
> > > field.
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > -Matthias
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > On 6/2/26 7:42 AM, Andrew
> > > > > Schofield
> > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > > Following on from the
> > > > > discussion
> > > > > > > in the
> > > > > > > > > > > > > > community,
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > difficulty
> > > > > > > > > > > > > > > > > > > > > > > > > of trying to accommodate
> the
> > > client
> > > > > > > > > instance ID
> > > > > > > > > > > > in a
> > > > > > > > > > > > > > > > tagged
> > > > > > > > > > > > > > > > > > field
> > > > > > > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > > > > > > > > acceptable complexity, I
> have
> > > made
> > > > > a
> > > > > > > > > significant
> > > > > > > > > > > > > > change
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > the KIP.
> > > > > > > > > > > > > > > > > > > > > > > Now, it
> > > > > > > > > > > > > > > > > > > > > > > > > introduces v3 of the
> request
> > > header
> > > > > > > > > containing
> > > > > > > > > > > > the
> > > > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > > > > ID
> > > > > > > > > > > > > > > > > > > > > > > as a
> > > > > > > > > > > > > > > > > > > > > > > > > proper field.
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/KAFKA/KIP-1313*3A*Client*instance*ID*in*all*request*headers__;JSsrKysrKys!!Ayb5sqE7!pUZS25PuTKdhiqvTGcwDKbclqpG8dFOzw2Ax9WxVM6Sb09PVQ0gl1i0gjlr2_Krr66agbuVC2qLGgUcg7vrW$
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Please review and let
> me
> > > know
> > > > > what
> > > > > > > you
> > > > > > > > > think.
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > On 2026/05/28 21:51:01
> > > > > "Matthias J.
> > > > > > > > > Sax"
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > >> Thanks Andrew. I
> agree to
> > > the
> > > > > > > issue
> > > > > > > > > that
> > > > > > > > > > > > tagged
> > > > > > > > > > > > > > > > fields
> > > > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > > > > > optional.
> > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > >> Nevertheless, I find
> the
> > > > > proposed
> > > > > > > > > > > > compatibility
> > > > > > > > > > > > > > > > > > protocol too
> > > > > > > > > > > > > > > > > > > > > > > complex
> > > > > > > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > > > > > > >> unnecessary, and would
> > > still
> > > > > > > prefer a
> > > > > > > > > > > > version
> > > > > > > > > > > > > > bump
> > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > `GetTelemetrySubscriptionsRequest/Reponse`
> > > > > > > > > > > > to
> > > > > > > > > > > > > > clean
> > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > > > > > > > up. --
> > > > > > > > > > > > > > > > > > > > > > > For
> > > > > > > > > > > > > > > > > > > > > > > > > > >>
> `PushTelemetryRequest` the
> > > > > > > argument
> > > > > > > > > from
> > > > > > > > > > > > above
> > > > > > > > > > > > > > > > applies,
> > > > > > > > > > > > > > > > > > so
> > > > > > > > > > > > > > > > > > > > > > > leaving it
> > > > > > > > > > > > > > > > > > > > > > > > > > >> untouched is ok.
> > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > >> I don't see why
> > > > > > > > > > > > > > `GetTelemetrySubscriptionsRequest`
> > > > > > > > > > > > > > > > > > would need
> > > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > > > > encode
> > > > > > > > > > > > > > > > > > > > > > > > > > >> the `clientInstandId`
> in
> > > it's
> > > > > > > request
> > > > > > > > > body.
> > > > > > > > > > > > > > Given
> > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > > > >> `clientInstanceId` is
> a
> > > random
> > > > > > > UUID,
> > > > > > > > > the
> > > > > > > > > > > > > > returned
> > > > > > > > > > > > > > > > > > subscription
> > > > > > > > > > > > > > > > > > > > > > > cannot
> > > > > > > > > > > > > > > > > > > > > > > > > > >> really depend on it.
> So
> > > why
> > > > > would
> > > > > > > we
> > > > > > > > > need to
> > > > > > > > > > > > > > send
> > > > > > > > > > > > > > > > it to
> > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > broker?
> > > > > > > > > > > > > > > > > > > > > > > > > > >> Right now, it's set to
> > > ZERO
> > > > > only
> > > > > > > for
> > > > > > > > > the
> > > > > > > > > > > > > > purpose to
> > > > > > > > > > > > > > > > get
> > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > broker to
> > > > > > > > > > > > > > > > > > > > > > > > > > >> assign a new UUID.
> But it
> > > has
> > > > > > > nothing
> > > > > > > > > to do
> > > > > > > > > > > > > > with the
> > > > > > > > > > > > > > > > > > actual
> > > > > > > > > > > > > > > > > > > > > "what
> > > > > > > > > > > > > > > > > > > > > > > > > > >> metrics should I send"
> > > > > question.
> > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > >> To be fair, KIP-714
> lists
> > > > > > > > > > > > `client_instance_id`
> > > > > > > > > > > > > > as a
> > > > > > > > > > > > > > > > > > field that
> > > > > > > > > > > > > > > > > > > > > > > can be
> > > > > > > > > > > > > > > > > > > > > > > > > > >> used to define a
> > > subscription.
> > > > > > > But it
> > > > > > > > > seems
> > > > > > > > > > > > > > rather
> > > > > > > > > > > > > > > > > > useless in
> > > > > > > > > > > > > > > > > > > > > > > practice
> > > > > > > > > > > > > > > > > > > > > > > > > > >> to me? I a user
> defines a
> > > > > > > > > subscription, they
> > > > > > > > > > > > > > cannot
> > > > > > > > > > > > > > > > > > know the
> > > > > > > > > > > > > > > > > > > > > UUID.
> > > > > > > > > > > > > > > > > > > > > > > > > Thus,
> > > > > > > > > > > > > > > > > > > > > > > > > > >> I think we should
> actually
> > > > > drop
> > > > > > > > > supporting
> > > > > > > > > > > > > > > > > > > > > `client_instance_id`
> > > > > > > > > > > > > > > > > > > > > > > as a
> > > > > > > > > > > > > > > > > > > > > > > > > > >> "subscription matching
> > > > > > > parameter"? Of
> > > > > > > > > > > > course,
> > > > > > > > > > > > > > there
> > > > > > > > > > > > > > > > is a
> > > > > > > > > > > > > > > > > > > > > backward
> > > > > > > > > > > > > > > > > > > > > > > > > > >> compatibility
> question,
> > > but I
> > > > > > > think
> > > > > > > > > we can
> > > > > > > > > > > > > > address
> > > > > > > > > > > > > > > > > > this: if
> > > > > > > > > > > > > > > > > > > > > > > brokers
> > > > > > > > > > > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > > > > > > > > >> upgraded and they
> have an
> > > > > existing
> > > > > > > > > > > > > > > > `client_instance_id`
> > > > > > > > > > > > > > > > > > based
> > > > > > > > > > > > > > > > > > > > > > > > > > >> subscription defined,
> they
> > > > > could
> > > > > > > > > advertise
> > > > > > > > > > > > to
> > > > > > > > > > > > > > only
> > > > > > > > > > > > > > > > > > support
> > > > > > > > > > > > > > > > > > > > > v0, and
> > > > > > > > > > > > > > > > > > > > > > > > > they
> > > > > > > > > > > > > > > > > > > > > > > > > > >> should log a warning
> that
> > > this
> > > > > > > > > feature is
> > > > > > > > > > > > > > > > deprecated.
> > > > > > > > > > > > > > > > > > New
> > > > > > > > > > > > > > > > > > > > > brokers
> > > > > > > > > > > > > > > > > > > > > > > > > would
> > > > > > > > > > > > > > > > > > > > > > > > > > >> also not allow to use
> > > > > > > > > `client_instance_id`
> > > > > > > > > > > > any
> > > > > > > > > > > > > > > > longer to
> > > > > > > > > > > > > > > > > > > > > define a
> > > > > > > > > > > > > > > > > > > > > > > > > > >> subscription.
> > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > >> Similarly, for
> > > > > > > > > > > > > > `GetTelemetrySubscriptionsResponse`,
> > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > only
> > > > > > > > > > > > > > > > > > > > > need
> > > > > > > > > > > > > > > > > > > > > > > > > > >> `clientInstanceId` if
> the
> > > > > broker
> > > > > > > > > computes
> > > > > > > > > > > > the
> > > > > > > > > > > > > > UUID.
> > > > > > > > > > > > > > > > But
> > > > > > > > > > > > > > > > > > if we
> > > > > > > > > > > > > > > > > > > > > let
> > > > > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > > > >> client compute it,
> this
> > > field
> > > > > is
> > > > > > > not
> > > > > > > > > needed
> > > > > > > > > > > > any
> > > > > > > > > > > > > > > > longer.
> > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > >> -Matthias
> > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > >> On 5/28/26 1:21 AM,
> Andrew
> > > > > > > Schofield
> > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > >>> Hi Jun,
> > > > > > > > > > > > > > > > > > > > > > > > > > >>> Thanks for your
> response.
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>> JR24: I'll update
> the KIP
> > > > > > > shortly.
> > > > > > > > > Here's a
> > > > > > > > > > > > > > > > summary.
> > > > > > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > > > > > > various
> > > > > > > > > > > > > > > > > > > > > > > > > modern group protocol
> heartbeat
> > > > > > > requests
> > > > > > > > > encode
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > member
> > > > > > > > > > > > > > > > > > ID as a
> > > > > > > > > > > > > > > > > > > > > > > string
> > > > > > > > > > > > > > > > > > > > > > > > > for historical reasons,
> even
> > > though
> > > > > > > it's in
> > > > > > > > > > > > practice
> > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > UUID.
> > > > > > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > > > > > > Apache
> > > > > > > > > > > > > > > > > > > > > > > > > Kafka Java client happens
> to
> > > use
> > > > > > > > > > > > > > > > > > org.apache.kafka.common.Uuid to
> > > > > > > > > > > > > > > > > > > > > > > create the
> > > > > > > > > > > > > > > > > > > > > > > > > member ID and convert it
> into a
> > > > > string.
> > > > > > > > > This
> > > > > > > > > > > > means
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > when
> > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > > clientInstanceId is
> converted
> > > into
> > > > > a
> > > > > > > > > string, its
> > > > > > > > > > > > > > encoding
> > > > > > > > > > > > > > > > > > matches
> > > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > > member ID and it all lines
> up.
> > > > > However,
> > > > > > > > > there are
> > > > > > > > > > > > > > other
> > > > > > > > > > > > > > > > ways
> > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > encode
> > > > > > > > > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > > > > > > > > UUID into a string and I
> know
> > > for a
> > > > > > > fact
> > > > > > > > > that the
> > > > > > > > > > > > > > > > librdkafka
> > > > > > > > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > > > > > > > does it
> > > > > > > > > > > > > > > > > > > > > > > > > differently.
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>> Thanks,
> > > > > > > > > > > > > > > > > > > > > > > > > > >>> Andrew
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>> On 2026/05/27
> 17:11:25
> > > Jun
> > > > > Rao
> > > > > > > via
> > > > > > > > > dev
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>> Hi, Andrew,
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>> Thanks for the
> reply.
> > > One
> > > > > more
> > > > > > > > > comment.
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>> JR24. "The
> alignment of
> > > > > other
> > > > > > > > > identifiers
> > > > > > > > > > > > is
> > > > > > > > > > > > > > by
> > > > > > > > > > > > > > > > > > convention
> > > > > > > > > > > > > > > > > > > > > (and
> > > > > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > > Java
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>> client will follow
> the
> > > > > > > convention)
> > > > > > > > > rather
> > > > > > > > > > > > than
> > > > > > > > > > > > > > > > > > mandate."
> > > > > > > > > > > > > > > > > > > > > Could
> > > > > > > > > > > > > > > > > > > > > > > you
> > > > > > > > > > > > > > > > > > > > > > > > > describe
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>> the convention to
> > > convert a
> > > > > > > > > > > > clientInstanceId
> > > > > > > > > > > > > > > > (UUID)
> > > > > > > > > > > > > > > > > > to a
> > > > > > > > > > > > > > > > > > > > > > > memberId
> > > > > > > > > > > > > > > > > > > > > > > > > (String)?
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>> Jun
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>> On Tue, May 19,
> 2026 at
> > > > > 2:36 AM
> > > > > > > > > Andrew
> > > > > > > > > > > > > > Schofield <
> > > > > > > > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> 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 <
> > > > > > > > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>> 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 <
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>
> > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> 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 <
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>
> > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> 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
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] KIP-1313: Client instance ID in all request headers

[Andrew Schofield <sc...@apache.org>]

Hi Jun,
Thanks for your reply.

JR39: KIP description tightened up. That should do the trick.

Thanks,
Andrew

On 2026/08/05 17:28:34 Jun Rao via dev wrote:
> Hi, Andrew,
> 
> Thanks for the reply.
> 
> JR39. For clientInstanceID, we have: "If a client specifies a reserved
> client instance ID (zero or one), the request will be rejected with error
> code INVALID_REQUEST ."
> For clientId, we have: "After this KIP, the broker will assume that the
> client ID from the initial request applies to all subsequent requests
> on a connection,
> and it will ignore the client ID specified on any subsequent requests."
> Could we make the behavior consistent between these two?
> 
> Jun
> 
> 
> On Tue, Aug 4, 2026 at 1:05 PM Andrew Schofield <sc...@apache.org>
> wrote:
> 
> > Hi Jun,
> > Thanks for the reply.
> >
> > JR37: It had escaped me that ClientInstanceId is a tagged field, so you're
> > absolutely right. (I am not an AI.) I'll update the KIP.
> >
> > Thanks,
> > Andrew
> >
> > On 2026/08/04 18:24:19 Jun Rao via dev wrote:
> > > Hi, Andrew,
> > >
> > > Thanks for the reply.
> > >
> > > JR37. UUID is 16 bytes. If it's omitted in subsequent requests, we save
> > 16
> > > bytes, right?
> > >
> > > Jun
> > >
> > >
> > >
> > > On Tue, Aug 4, 2026 at 5:47 AM Andrew Schofield <sc...@apache.org>
> > > wrote:
> > >
> > > > Hi Jun,
> > > > Thanks for your reply.
> > > >
> > > > JR37: Unlike with clientId where space is saved by not transmitting it
> > on
> > > > every request, there's nothing to be gained by omitting
> > clientInstanceId on
> > > > later requests. I prefer to leave it as is.
> > > >
> > > > JR38: OK, I've updated those paragraphs in the KIP to exclude the
> > reserved
> > > > UUIDs.
> > > >
> > > > Thanks,
> > > > Andrew
> > > >
> > > > On 2026/08/03 20:23:39 Jun Rao via dev wrote:
> > > > > Hi, Andrew,
> > > > >
> > > > > Thanks for the reply.
> > > > >
> > > > > JR37. Will it be better to require ClientInstanceId only on the first
> > > > > request, to be consistent with clientId?
> > > > >
> > > > > JR38. "must specify a non-zero client instance ID". one_uuid is also
> > a
> > > > > reserved one in the Uuid class. Should we exclude that one too?
> > > > >
> > > > > Jun
> > > > >
> > > > > On Fri, Jul 31, 2026 at 9:10 AM Andrew Schofield <
> > schofielaj@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Hi Jun,
> > > > > > Thanks for the reply and sorry for the delay. Lots of 4.4 stuff
> > got in
> > > > the
> > > > > > way.
> > > > > >
> > > > > > JR34: EligibleLeaderReplicasVersion and KRaftVersion also use
> > > > ApiVersion
> > > > > > to negotiate the RPC versions. I do not believe we need to bump up
> > > > other
> > > > > > feature versions as a result of the RPC version bumps in this KIP.
> > > > > >
> > > > > > JR35: Yes, good catch. In order to handle client ID-based quotas
> > for
> > > > > > forwarded requests, it will be necessary to populate the client ID
> > in
> > > > the
> > > > > > forwarded request header. KIP updated.
> > > > > >
> > > > > > JR36: I hadn't considered MV to be a feature version, but I
> > understand.
> > > > > > KIP updated.
> > > > > >
> > > > > > Thanks,
> > > > > > Andrew
> > > > > >
> > > > > > On 2026/06/29 16:23:09 Jun Rao via dev wrote:
> > > > > > > Hi, Andrew,
> > > > > > >
> > > > > > > Thanks for the reply.
> > > > > > >
> > > > > > > JR34. Transaction coordinator uses ApiVersion to negotiate the
> > PRC
> > > > > > > versions. Therefore, if there is no functional change, there is
> > no
> > > > need
> > > > > > to
> > > > > > > bump the TV version. I am not sure about
> > > > EligibleLeaderReplicasVersion
> > > > > > > and KRaftVersion.
> > > > > > > It would be useful to have the experts chime in.
> > > > > > >
> > > > > > > JR35. Envelope/forwarding interaction: When a broker forwards a
> > > > client
> > > > > > > request to the controller via EnvelopeUtils
> > > > > > (parseForwardedRequestHeader),
> > > > > > > the inner header may have its clientId optimized to null. Some
> > quota
> > > > > > > enforcement (e.g. controller mutation) may depend on the non-null
> > > > > > clientId.
> > > > > > > The per-connection caching occurs on the original client↔broker
> > > > > > connection, not
> > > > > > > the broker↔controller one. Should the forwarded request preserve
> > the
> > > > > > > non-null resolved (cached) client.id?
> > > > > > >
> > > > > > > JR36. "This KIP does not need to introduce any feature version
> > > > bumps."
> > > > > > This
> > > > > > > is not very accurate since MV is a feature version and is bumped.
> > > > > > >
> > > > > > > Jun
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Jun 26, 2026 at 12:42 AM Andrew Schofield <
> > > > schofielaj@apache.org
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi Jun,
> > > > > > > > I've updated the KIP.
> > > > > > > >
> > > > > > > > JS34: I don't believe that we need to introduce any new feature
> > > > > > versions
> > > > > > > > for this KIP. For example, we do not need a new ShareVersion
> > since
> > > > that
> > > > > > > > enabled share groups (SV_1) and controls the versioning of the
> > > > records
> > > > > > on
> > > > > > > > the internal topics (SV_2). I think the same applies for the
> > > > others. I
> > > > > > > > understand GroupVersion and StreamsVersion, and I think they
> > > > follow the
> > > > > > > > same reasoning as ShareVersion. I don't know
> > TransactionVersion or
> > > > > > > > EligibleLeaderReplicasVersion, so let me know whether those are
> > > > > > different
> > > > > > > > in this regard.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Andrew
> > > > > > > >
> > > > > > > > On 2026/06/25 21:32:27 Andrew Schofield wrote:
> > > > > > > > > Hi Jun,
> > > > > > > > > Thanks for the reply.
> > > > > > > > >
> > > > > > > > > JR27: Yes, makes sense. So request header v3 is
> > binary-compatible
> > > > > > with
> > > > > > > > request header v2.
> > > > > > > > >
> > > > > > > > > JS34: Yes, I think so.
> > > > > > > > >
> > > > > > > > > I'll update the KIP tomorrow morning.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Andrew
> > > > > > > > >
> > > > > > > > > On 2026/06/25 20:23:57 Jun Rao via dev wrote:
> > > > > > > > > > Hi, Andrew,
> > > > > > > > > >
> > > > > > > > > > Thanks for the reply.
> > > > > > > > > >
> > > > > > > > > > JR27. I was thinking of the following, which is slightly
> > > > different
> > > > > > from
> > > > > > > > > > what you described.
> > > > > > > > > > * Bump RequestHeader to v3, and introduce ClientInstanceId
> > as a
> > > > > > tagged
> > > > > > > > > > field for versions 3+ and change the semantic of the
> > existing
> > > > field
> > > > > > > > > > clientId (only need to be populated by the first request).
> > > > > > > > > > * Bump the request versions for all RPCs including
> > ApiVersion
> > > > and
> > > > > > map
> > > > > > > > to
> > > > > > > > > > the new version to use v3 of RequestHeader.
> > > > > > > > > > * On the server side, when a new request version is seen,
> > we
> > > > > > enforce
> > > > > > > > the
> > > > > > > > > > presence of ClientInstanceId and reject the request if it
> > is
> > > > > > missing.
> > > > > > > > > > Essentially, treat it as a required field. We also cache
> > the
> > > > > > clientId
> > > > > > > > from
> > > > > > > > > > the first request and ignore it from subsequent ones.
> > > > > > > > > > * We would introduce OffsetDelete v1 as the first flexible
> > > > version
> > > > > > so
> > > > > > > > that
> > > > > > > > > > it uses the v3 request header.
> > > > > > > > > > * We would update PushTelemetry and
> > GetTelemetrySubscriptions
> > > > as
> > > > > > > > described
> > > > > > > > > > in the KIP and the ClientInstanceId would move to the
> > request
> > > > > > header.
> > > > > > > > > >
> > > > > > > > > > In the future, if we want to add a new truly optional
> > field to
> > > > > > > > > > RequestHeader, we can continue adding it as a tagged field
> > > > without
> > > > > > > > bumping
> > > > > > > > > > up the request version. To add a required field, we will
> > add
> > > > it as
> > > > > > a
> > > > > > > > tagged
> > > > > > > > > > field but force a version bump to all requests.
> > > > > > > > > >
> > > > > > > > > > The benefit of this approach is that (1) it's compatible
> > with
> > > > the
> > > > > > > > format of
> > > > > > > > > > the old request header; (2) it avoids duplicating new
> > fields;
> > > > and
> > > > > > (3)
> > > > > > > > there
> > > > > > > > > > is no constraint on deprecating the old request header.
> > It's
> > > > > > slightly
> > > > > > > > weird
> > > > > > > > > > to bump up the version when adding a tagged field. But it
> > still
> > > > > > seems
> > > > > > > > > > better than the alternatives.
> > > > > > > > > >
> > > > > > > > > > JR34. Since we now have different feature versions gating
> > > > different
> > > > > > > > RPCs,
> > > > > > > > > > should we bump up GV, TV, etc., too?
> > > > > > > > > >
> > > > > > > > > > Jun
> > > > > > > > > >
> > > > > > > > > > On Thu, Jun 25, 2026 at 10:37 AM Andrew Schofield <
> > > > > > > > schofielaj@apache.org>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi Jun,
> > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > >
> > > > > > > > > > > JR27.1: What if we want to add non-optional fields to the
> > > > request
> > > > > > > > header
> > > > > > > > > > > in the future? I think that such fields would be by
> > > > definition
> > > > > > future
> > > > > > > > > > > fields which would not be understood by existing
> > brokers. For
> > > > > > > > serialization
> > > > > > > > > > > reasons, I think we would use version 2+ tagged fields
> > and
> > > > the
> > > > > > > > requirement
> > > > > > > > > > > for non-optionality would be enforced by code, rather
> > than
> > > > by the
> > > > > > > > protocol
> > > > > > > > > > > schema. This avoids the field duplication.
> > > > > > > > > > >
> > > > > > > > > > > JR27.2: Yes, I don't like it, but when we inevitably do
> > > > another
> > > > > > > > KIP-896 to
> > > > > > > > > > > remove support for ancient parts of the protocol, it's
> > going
> > > > to
> > > > > > be
> > > > > > > > another
> > > > > > > > > > > KIP. That's all I meant.
> > > > > > > > > > >
> > > > > > > > > > > If I understand your proposal correctly compared with the
> > > > > > existing
> > > > > > > > KIP
> > > > > > > > > > > text, it would look like this:
> > > > > > > > > > > * Remove RequestHeader v3, and introduce
> > ClientInstanceId as
> > > > a
> > > > > > tagged
> > > > > > > > > > > field for versions 2+.
> > > > > > > > > > > * Bump the request versions for all RPCs. We'd update the
> > > > request
> > > > > > > > JSON
> > > > > > > > > > > schemas with something like "ClientInstanceIdVersions":
> > "X+".
> > > > > > This
> > > > > > > > would
> > > > > > > > > > > mean that the request would only be properly formed if it
> > > > had the
> > > > > > > > > > > ClientInstanceId present, and would also mean that
> > ClientId
> > > > > > could be
> > > > > > > > null
> > > > > > > > > > > for non-initial requests on each connection.
> > > > > > > > > > > * We would create ApiVersions v6, simply as a matter of
> > the
> > > > > > bumping
> > > > > > > > of
> > > > > > > > > > > request versions for all RPCs, but its schema would be
> > > > unchanged
> > > > > > > > from v5.
> > > > > > > > > > > * We would introduce OffsetDelete v1 as the first
> > flexible
> > > > > > version
> > > > > > > > so that
> > > > > > > > > > > it uses the v2 request header.
> > > > > > > > > > > * We would update PushTelemetry and
> > > > GetTelemetrySubscriptions as
> > > > > > > > described
> > > > > > > > > > > in the KIP and the ClientInstanceId would move to the
> > request
> > > > > > header.
> > > > > > > > > > >
> > > > > > > > > > > I think that works roughly the same as what we have
> > today. I
> > > > > > don't
> > > > > > > > really
> > > > > > > > > > > like the mandatory nature of the tagged field, but then I
> > > > don't
> > > > > > > > really like
> > > > > > > > > > > the way that ApiVersions is pegged on a historical
> > request
> > > > header
> > > > > > > > version.
> > > > > > > > > > >
> > > > > > > > > > > Do I have this correct? If so, I can update the KIP
> > > > accordingly.
> > > > > > > > > > >
> > > > > > > > > > > Thanks,
> > > > > > > > > > > Andrew
> > > > > > > > > > >
> > > > > > > > > > > On 2026/06/24 23:40:06 Jun Rao via dev wrote:
> > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > >
> > > > > > > > > > > > JR27.1 What if we want to add non-optional fields to
> > the
> > > > > > request
> > > > > > > > header
> > > > > > > > > > > in
> > > > > > > > > > > > the future? The choice I see is duplicating the field
> > in
> > > > the
> > > > > > new
> > > > > > > > request
> > > > > > > > > > > > header and the new ApiVersion request. But it's not
> > very
> > > > clean.
> > > > > > > > > > > > JR27.2 Requiring a major version API compatibility KIP
> > is
> > > > also
> > > > > > a
> > > > > > > > bit
> > > > > > > > > > > > awkward.
> > > > > > > > > > > >
> > > > > > > > > > > > Here is yet another proposal. We add the
> > ClientInstanceId
> > > > to
> > > > > > the
> > > > > > > > request
> > > > > > > > > > > > header as a tagged field and also bump up all request
> > > > versions.
> > > > > > > > This
> > > > > > > > > > > avoids
> > > > > > > > > > > > the header compatibility issue in SocketServer. The
> > > > bumped-up
> > > > > > > > version
> > > > > > > > > > > > signals that the new field is actually required. On the
> > > > server
> > > > > > > > side, when
> > > > > > > > > > > > receiving the new version of a request, we verify that
> > the
> > > > > > > > > > > ClientInstanceId
> > > > > > > > > > > > field exists. If it's not present, we reject the
> > request.
> > > > This
> > > > > > > > will be
> > > > > > > > > > > the
> > > > > > > > > > > > convention for adding future required fields to the
> > header.
> > > > > > > > Compared to
> > > > > > > > > > > the
> > > > > > > > > > > > current proposal, this avoids duplicating the field
> > between
> > > > > > request
> > > > > > > > > > > header
> > > > > > > > > > > > and ApiVersionRequest, and it provides a path for
> > > > deprecating
> > > > > > the
> > > > > > > > older
> > > > > > > > > > > > version of the request header. What do you think?
> > > > > > > > > > > >
> > > > > > > > > > > > Jun
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Jun 24, 2026 at 2:15 AM Andrew Schofield <
> > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > > >
> > > > > > > > > > > > > JR27: Yes, I enhanced that section of the KIP.
> > > > > > > > > > > > > JR27.1: This KIP was unusual because we wanted to
> > add a
> > > > > > concept
> > > > > > > > which
> > > > > > > > > > > > > existed in the KIP-714 RPCs to the request header,
> > > > > > complicating
> > > > > > > > the
> > > > > > > > > > > > > behavior of those RPCs, AND we wanted to change the
> > > > handling
> > > > > > of
> > > > > > > > client
> > > > > > > > > > > ID
> > > > > > > > > > > > > without breaking older brokers. If we simply wanted
> > to
> > > > add a
> > > > > > > > brand new
> > > > > > > > > > > > > field to the request header, we can do it as a tagged
> > > > field
> > > > > > in
> > > > > > > > request
> > > > > > > > > > > > > header versions 2+.
> > > > > > > > > > > > > JR27.2: Covered this too. We'd need a major version
> > API
> > > > > > > > compatibility
> > > > > > > > > > > KIP.
> > > > > > > > > > > > >
> > > > > > > > > > > > > JR31: Yes. KIP updated.
> > > > > > > > > > > > >
> > > > > > > > > > > > > JR32: Yes. This is a minor inconvenience I feel. KIP
> > > > updated.
> > > > > > > > > > > > >
> > > > > > > > > > > > > JR33: I don't see the value of a string comparison
> > here.
> > > > > > > > Personally,
> > > > > > > > > > > I'm
> > > > > > > > > > > > > happy with "assume".
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > Andrew
> > > > > > > > > > > > >
> > > > > > > > > > > > > On 2026/06/23 22:52:15 Jun Rao via dev wrote:
> > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > JR27. The code that changed the request header
> > parsing
> > > > was
> > > > > > > > > > > introduced in
> > > > > > > > > > > > > > 2019 (
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://urldefense.com/v3/__https://github.com/apache/kafka/pull/7372__;!!Ayb5sqE7!scbWbTEEm2o-Y3MBGi829H2cpMWPRyrF9g2CW3lmRHyRmgBU2MyoRif2mFJpnfmvQ2x7fF4LrAJXdwH86ERR$
> > > > > > > > > > > > > ). I agree that fixing it
> > > > > > > > > > > > > > now is too late. We should document the path
> > forward
> > > > for
> > > > > > > > ApiVersion.
> > > > > > > > > > > > > Could
> > > > > > > > > > > > > > we answer at least the following questions in the
> > > > > > > > Compatibility,
> > > > > > > > > > > > > > Deprecation, and Migration Plan section?
> > > > > > > > > > > > > > JR27.1 What happens to ApiVersion if we change the
> > > > request
> > > > > > > > header in
> > > > > > > > > > > the
> > > > > > > > > > > > > > future?
> > > > > > > > > > > > > > JR27.2 What happens if we ever want to deprecate
> > v2 of
> > > > the
> > > > > > > > request
> > > > > > > > > > > > > header?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > JR28. The new MV needs to be covered in the
> > > > Compatibility,
> > > > > > > > > > > Deprecation,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > Migration Plan section.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > JR31. "If a connection uses the v3 request header
> > in
> > > > its
> > > > > > first
> > > > > > > > > > > request,
> > > > > > > > > > > > > it
> > > > > > > > > > > > > > must specify a non-zero client instance ID and it
> > must
> > > > > > specify
> > > > > > > > the
> > > > > > > > > > > same
> > > > > > > > > > > > > > client instance ID for all subsequent requests."
> > > > > > > > > > > > > > Do we do the same if the first request is v6 of
> > > > ApiVersion?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > JR32. "For subsequent requests using an earlier
> > > > version of
> > > > > > the
> > > > > > > > > > > request
> > > > > > > > > > > > > > header, the client sends the client ID". This means
> > > > that
> > > > > > > > subsequent
> > > > > > > > > > > > > > ApiVersion V6 requests will carry the non-null
> > clientID
> > > > > > > > > > > unnecessarily.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > JR33. "After this KIP, the broker will assume that
> > the
> > > > > > client
> > > > > > > > ID
> > > > > > > > > > > from the
> > > > > > > > > > > > > > initial request applies to all subsequent requests
> > on a
> > > > > > > > connection,
> > > > > > > > > > > and
> > > > > > > > > > > > > it
> > > > > > > > > > > > > > will ignore the client ID specified on any
> > subsequent
> > > > > > > > requests."
> > > > > > > > > > > > > > Should the broker verify that the clientId from
> > > > subsequent
> > > > > > > > request
> > > > > > > > > > > match
> > > > > > > > > > > > > > the first cached one, if not null?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >  Jun
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Tue, Jun 23, 2026 at 6:05 AM Andrew Schofield <
> > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > Thanks for your reply.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR27: Unfortunately, I don't think this is
> > > > acceptable. We
> > > > > > > > would be
> > > > > > > > > > > > > saying
> > > > > > > > > > > > > > > that AK 4.5 clients can only connect to AK 4.5 or
> > > > later
> > > > > > > > brokers,
> > > > > > > > > > > and
> > > > > > > > > > > > > that
> > > > > > > > > > > > > > > we'd create patch release for AK 4.0.x to AK
> > 4.4.x.
> > > > so
> > > > > > AK 4.5
> > > > > > > > > > > clients
> > > > > > > > > > > > > could
> > > > > > > > > > > > > > > connect to those too. We'd be preventing
> > connection
> > > > to
> > > > > > AK 3.x
> > > > > > > > > > > brokers
> > > > > > > > > > > > > by AK
> > > > > > > > > > > > > > > 4.5 clients. I don't see how we can break
> > > > compatibility
> > > > > > in a
> > > > > > > > minor
> > > > > > > > > > > > > release.
> > > > > > > > > > > > > > > Here's the existing compatibility table:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://urldefense.com/v3/__https://kafka.apache.org/41/getting-started/compatibility/__;!!Ayb5sqE7!ppWU_jI9f7EY9DYwcbiOESSBG2TmPn9CHfLnVM5TaIMwWqHUbUbIiGre1GGKMr-HmelQlyP6ibUSyORCAgte$
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR29: OK, makes sense to me.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On 2026/06/22 21:50:43 Jun Rao via dev wrote:
> > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > JR27. I am not sure I like the approach of
> > pinning
> > > > the
> > > > > > > > header to
> > > > > > > > > > > v2
> > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > ApiVersionsRequest. This means that in the
> > future,
> > > > each
> > > > > > > > change
> > > > > > > > > > > to the
> > > > > > > > > > > > > > > > request header must be duplicated in the
> > request
> > > > > > itself.
> > > > > > > > Here is
> > > > > > > > > > > an
> > > > > > > > > > > > > > > > alternative. Note that to detect an unsupported
> > > > > > > > > > > ApiVersionRequest, we
> > > > > > > > > > > > > > > don't
> > > > > > > > > > > > > > > > need to parse the full v2 request header.
> > Parsing
> > > > the
> > > > > > > > first two
> > > > > > > > > > > > > fields
> > > > > > > > > > > > > > > > ApiKey and ApiVersion is enough. So, we could
> > > > patch all
> > > > > > > > the 4.x
> > > > > > > > > > > > > releases
> > > > > > > > > > > > > > > > with a change that short-circuits parsing the
> > full
> > > > > > request
> > > > > > > > header
> > > > > > > > > > > > > based
> > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > the first two fields. Then, we recommend
> > upgrading
> > > > > > from the
> > > > > > > > > > > latest
> > > > > > > > > > > > > 4.x
> > > > > > > > > > > > > > > > releases to future releases. This way, we can
> > > > still let
> > > > > > > > > > > > > > > ApiVersionsRequest
> > > > > > > > > > > > > > > > depend on the request header for current and
> > future
> > > > > > > > changes.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > JR29. The simplest thing is to upgrade the
> > KRaft
> > > > RPCs
> > > > > > too
> > > > > > > > to be
> > > > > > > > > > > > > > > consistent.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Sat, Jun 20, 2026 at 3:38 AM Andrew
> > Schofield <
> > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > Thanks for these insightful comments. I did
> > > > > > prototype the
> > > > > > > > > > > earlier
> > > > > > > > > > > > > v2
> > > > > > > > > > > > > > > > > request header with tagged fields variant. I
> > > > have now
> > > > > > > > > > > prototyped
> > > > > > > > > > > > > the v3
> > > > > > > > > > > > > > > > > request header variant.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > JR27: You were of course entirely correct
> > that a
> > > > new
> > > > > > > > version of
> > > > > > > > > > > > > > > > > ApiVersions request cannot use a request
> > header
> > > > > > which is
> > > > > > > > not
> > > > > > > > > > > > > > > > > binary-compatible with what has gone before.
> > As a
> > > > > > > > result, I
> > > > > > > > > > > have
> > > > > > > > > > > > > > > introduced
> > > > > > > > > > > > > > > > > a new version of ApiVersions request which
> > > > includes
> > > > > > > > > > > > > ClientInstanceId
> > > > > > > > > > > > > > > in the
> > > > > > > > > > > > > > > > > request body but continues to use the v2
> > request
> > > > > > header.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > JR28: Yes, we need a new metadata version,
> > which
> > > > is
> > > > > > > > > > > provisionally
> > > > > > > > > > > > > > > > > IBP_4_5_IV0. I'll update the KIP with the
> > final
> > > > value
> > > > > > > > when it
> > > > > > > > > > > is
> > > > > > > > > > > > > > > assigned.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > JR29: I don't have any strong feelings on
> > this. I
> > > > > > > > suppose for
> > > > > > > > > > > each
> > > > > > > > > > > > > > > inter
> > > > > > > > > > > > > > > > > broker RPC version that is bumped, we need to
> > > > > > introduce
> > > > > > > > an MV
> > > > > > > > > > > > > check. We
> > > > > > > > > > > > > > > > > cannot avoid this for RPCs which are also
> > used by
> > > > > > > > clients such
> > > > > > > > > > > as
> > > > > > > > > > > > > > > Fetch.
> > > > > > > > > > > > > > > > > For purely inter-broker RPCs, we could just
> > > > exempt
> > > > > > them
> > > > > > > > from
> > > > > > > > > > > the
> > > > > > > > > > > > > > > version
> > > > > > > > > > > > > > > > > bump. What do you recommend here?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > JR30: Done. INVALID_REQUEST. I did consider
> > > > > > permitting
> > > > > > > > zero
> > > > > > > > > > > client
> > > > > > > > > > > > > > > > > instance ID for inter-broker connections,
> > but I
> > > > > > decided
> > > > > > > > that I
> > > > > > > > > > > > > > > preferred
> > > > > > > > > > > > > > > > > not creating another rule.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On 2026/06/17 22:45:07 Andrew Schofield
> > wrote:
> > > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > JR27: I am familiar with KIP-511 and the
> > > > oddness of
> > > > > > > > > > > ApiVersions.
> > > > > > > > > > > > > You
> > > > > > > > > > > > > > > > > make an excellent point. I suspect that
> > > > > > > > ApiVersionsRequest will
> > > > > > > > > > > > > have
> > > > > > > > > > > > > > > to be
> > > > > > > > > > > > > > > > > limited to the v2 request header, just as it
> > is
> > > > > > > > restricted to
> > > > > > > > > > > the
> > > > > > > > > > > > > v0
> > > > > > > > > > > > > > > > > response header.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I'll do some experimentation.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On 2026/06/17 17:35:17 Jun Rao via dev
> > wrote:
> > > > > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Thanks for the reply. A few more
> > comments.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > JR27. It seems that we have a
> > compatibility
> > > > issue
> > > > > > > > with
> > > > > > > > > > > > > > > > > ApiVersionRequest v6
> > > > > > > > > > > > > > > > > > > depending on RequestHeader v3. This
> > happens
> > > > when
> > > > > > a
> > > > > > > > new
> > > > > > > > > > > client
> > > > > > > > > > > > > > > issues
> > > > > > > > > > > > > > > > > > > ApiVersionRequest v6 to an old broker
> > (one
> > > > that
> > > > > > only
> > > > > > > > > > > supports
> > > > > > > > > > > > > > > > > > > ApiVersionRequest v5). The SocketServer
> > in
> > > > the
> > > > > > > > broker will
> > > > > > > > > > > > > first
> > > > > > > > > > > > > > > try to
> > > > > > > > > > > > > > > > > > > read the request header. It tries to
> > find the
> > > > > > header
> > > > > > > > > > > version
> > > > > > > > > > > > > from
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > request version. Since the broker doesn't
> > > > know
> > > > > > > > > > > > > ApiVersionRequest
> > > > > > > > > > > > > > > v6, it
> > > > > > > > > > > > > > > > > > > uses v2 to parse the request header.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > The v2's wire format for the request
> > header
> > > > is:
> > > > > > > > ApiKey |
> > > > > > > > > > > > > > > ApiVersion |
> > > > > > > > > > > > > > > > > > > CorrelationId | ClientId |
> > > > tagged-fields-varint
> > > > > > > > > > > > > > > > > > > The v3's wire format for the request
> > header
> > > > is:
> > > > > > > > ApiKey |
> > > > > > > > > > > > > > > ApiVersion |
> > > > > > > > > > > > > > > > > > > CorrelationId | ClientId |
> > > > ClientInstanceId(16
> > > > > > > > bytes) |
> > > > > > > > > > > > > > > tagged-fields
> > > > > > > > > > > > > > > > > varint
> > > > > > > > > > > > > > > > > > > The first 4 fields are identical,
> > allowing
> > > > the
> > > > > > > > broker to
> > > > > > > > > > > parse
> > > > > > > > > > > > > > > them.
> > > > > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > > > > broker then tries to read the
> > > > > > tagged-fields-varint
> > > > > > > > using
> > > > > > > > > > > the
> > > > > > > > > > > > > > > serialized
> > > > > > > > > > > > > > > > > > > bytes intended for ClientInstanceId. This
> > > > could
> > > > > > lead
> > > > > > > > to a
> > > > > > > > > > > > > parsing
> > > > > > > > > > > > > > > > > error and
> > > > > > > > > > > > > > > > > > > raise an invalid request error. The
> > broker
> > > > will
> > > > > > > > close the
> > > > > > > > > > > > > > > connection
> > > > > > > > > > > > > > > > > > > instead of sending a v0 response for
> > > > > > > > ApiVersionRequest.
> > > > > > > > > > > Then
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > > > will never be able to detect supported
> > API
> > > > > > versions
> > > > > > > > on the
> > > > > > > > > > > old
> > > > > > > > > > > > > > > broker.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > The same problem didn't exist when
> > > > > > ApiVersionRequest
> > > > > > > > > > > changed
> > > > > > > > > > > > > from
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > v1
> > > > > > > > > > > > > > > > > > > request header to v2 because the wire
> > format
> > > > for
> > > > > > v1
> > > > > > > > is a
> > > > > > > > > > > > > prefix of
> > > > > > > > > > > > > > > v2.
> > > > > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > > > > problem exists for this KIP because the
> > wire
> > > > > > format
> > > > > > > > of v2
> > > > > > > > > > > is no
> > > > > > > > > > > > > > > longer
> > > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > > prefix of v3.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > JR28. Since we are bumping up the
> > version of
> > > > > > inter
> > > > > > > > broker
> > > > > > > > > > > > > > > requests, we
> > > > > > > > > > > > > > > > > need
> > > > > > > > > > > > > > > > > > > to gate them by introducing a new MV.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > JR29. Could you specify whether the
> > version
> > > > for
> > > > > > > > KRaft PRCs
> > > > > > > > > > > > > will be
> > > > > > > > > > > > > > > > > bumped
> > > > > > > > > > > > > > > > > > > too?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > JR30. "If a connection uses the v3
> > request
> > > > > > header in
> > > > > > > > its
> > > > > > > > > > > first
> > > > > > > > > > > > > > > > > request, it
> > > > > > > > > > > > > > > > > > > must specify a non-zero client instance
> > ID"
> > > > > > > > > > > > > > > > > > > Could we define the broker's behavior
> > when a
> > > > v3
> > > > > > > > request
> > > > > > > > > > > header
> > > > > > > > > > > > > > > > > contains a 0
> > > > > > > > > > > > > > > > > > > client instance ID?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Tue, Jun 16, 2026 at 1:25 AM Andrew
> > > > Schofield
> > > > > > <
> > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > JR26: Yes, I was considering open-ended
> > > > version
> > > > > > > > ranges.
> > > > > > > > > > > I've
> > > > > > > > > > > > > > > updated
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > KIP.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Now that we have a new request header
> > > > version,
> > > > > > I
> > > > > > > > think
> > > > > > > > > > > it's
> > > > > > > > > > > > > safe
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > reintroduce the client ID optimisation.
> > > > I've
> > > > > > added
> > > > > > > > that
> > > > > > > > > > > into
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > KIP
> > > > > > > > > > > > > > > > > also.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Let me know what you think.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On 2026/06/15 17:46:00 Jun Rao via dev
> > > > wrote:
> > > > > > > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Thanks for the reply. Just a minor
> > > > comment.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > JR26. "The keys of the map are either
> > > > single
> > > > > > > > versions
> > > > > > > > > > > like
> > > > > > > > > > > > > "0"
> > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > > closed
> > > > > > > > > > > > > > > > > > > > > version ranges like "1-2"."
> > > > > > > > > > > > > > > > > > > > > It will be useful to support
> > open-ended
> > > > > > > > versions. That
> > > > > > > > > > > way,
> > > > > > > > > > > > > > > "3":
> > > > > > > > > > > > > > > > > "3"
> > > > > > > > > > > > > > > > > > > > could
> > > > > > > > > > > > > > > > > > > > > be "3+": "3". This part won't need to
> > > > change
> > > > > > in
> > > > > > > > the
> > > > > > > > > > > future
> > > > > > > > > > > > > > > when we
> > > > > > > > > > > > > > > > > bump
> > > > > > > > > > > > > > > > > > > > up
> > > > > > > > > > > > > > > > > > > > > the request version without changing
> > the
> > > > > > header.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Fri, Jun 12, 2026 at 2:12 PM
> > Andrew
> > > > > > Schofield
> > > > > > > > <
> > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > JR25: I agree. I've changed to a
> > > > > > > > headerVersions map
> > > > > > > > > > > in
> > > > > > > > > > > > > both
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > request
> > > > > > > > > > > > > > > > > > > > > > and response schemas.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Let me know what you think.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On 2026/06/12 03:39:39 Jun Rao via
> > dev
> > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Thanks for the updated KIP.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > JR25. I have some concerns about
> > > > adding
> > > > > > the
> > > > > > > > > > > > > > > > > clientInstanceIdVersions
> > > > > > > > > > > > > > > > > > > > > > field
> > > > > > > > > > > > > > > > > > > > > > > to the schema. First of all, it
> > only
> > > > > > applies
> > > > > > > > to
> > > > > > > > > > > > > requests,
> > > > > > > > > > > > > > > but
> > > > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > > > > > > > responses. So, it's a bit weird
> > to
> > > > add
> > > > > > it to
> > > > > > > > the
> > > > > > > > > > > > > general
> > > > > > > > > > > > > > > > > schema.
> > > > > > > > > > > > > > > > > > > > > > Secondly,
> > > > > > > > > > > > > > > > > > > > > > > it's very specific to the new
> > field
> > > > > > added to
> > > > > > > > the
> > > > > > > > > > > > > request
> > > > > > > > > > > > > > > > > header. If
> > > > > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > > > > change the request header again
> > in
> > > > the
> > > > > > > > future, we
> > > > > > > > > > > need
> > > > > > > > > > > > > > > another
> > > > > > > > > > > > > > > > > way
> > > > > > > > > > > > > > > > > > > > to map
> > > > > > > > > > > > > > > > > > > > > > > request versions to the new
> > header
> > > > > > version.
> > > > > > > > > > > Ideally, we
> > > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > > > have a
> > > > > > > > > > > > > > > > > > > > > > > generic way to map request
> > versions
> > > > to
> > > > > > all
> > > > > > > > future
> > > > > > > > > > > > > header
> > > > > > > > > > > > > > > > > versions.
> > > > > > > > > > > > > > > > > > > > One
> > > > > > > > > > > > > > > > > > > > > > > possibility is to introduce a
> > > > > > headerVersion
> > > > > > > > field
> > > > > > > > > > > in
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > schema.
> > > > > > > > > > > > > > > > > > > > Then,
> > > > > > > > > > > > > > > > > > > > > > each
> > > > > > > > > > > > > > > > > > > > > > > request/response can use this
> > field
> > > > to
> > > > > > map
> > > > > > > > its
> > > > > > > > > > > > > versions to
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > header
> > > > > > > > > > > > > > > > > > > > > > > versions.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > On Tue, Jun 9, 2026 at 4:55 AM
> > Andrew
> > > > > > > > Schofield <
> > > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Hi Matthias,
> > > > > > > > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > I have change the version
> > property
> > > > for
> > > > > > > > > > > introducing
> > > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > > > ID
> > > > > > > > > > > > > > > > > > > > > > into
> > > > > > > > > > > > > > > > > > > > > > > > the request headers to be
> > > > > > > > > > > `clientInstanceIdVersions`
> > > > > > > > > > > > > > > which
> > > > > > > > > > > > > > > > > is now
> > > > > > > > > > > > > > > > > > > > an
> > > > > > > > > > > > > > > > > > > > > > > > open-ended range, such as "3+",
> > > > more
> > > > > > > > closely
> > > > > > > > > > > matching
> > > > > > > > > > > > > > > what
> > > > > > > > > > > > > > > > > we have
> > > > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > > > > flexible versions.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > I also added a change to the
> > > > > > > > > > > > > > > > > RebalanceConsumer.clientInstanceId
> > > > > > > > > > > > > > > > > > > > method
> > > > > > > > > > > > > > > > > > > > > > > > introduced in KIP-1306.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > On 2026/06/03 18:31:06
> > "Matthias J.
> > > > > > Sax"
> > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > Thanks Andrew.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >  From a KIP-714 perspective,
> > > > this is
> > > > > > a
> > > > > > > > great
> > > > > > > > > > > > > change,
> > > > > > > > > > > > > > > as it
> > > > > > > > > > > > > > > > > make
> > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > new
> > > > > > > > > > > > > > > > > > > > > > > > > RPCs and client/broker
> > > > cross-version
> > > > > > > > > > > compatibility
> > > > > > > > > > > > > > > clean.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > One question about your
> > > > > > `DeleteGroups`
> > > > > > > > RPC
> > > > > > > > > > > example.
> > > > > > > > > > > > > > > Should
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > new
> > > > > > > > > > > > > > > > > > > > > > > > > version of the RPC say
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > "clientInstanceIdVersion":
> > > > "3+",
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > ie, 3+ instead of 3? Similar
> > for
> > > > > > other
> > > > > > > > request,
> > > > > > > > > > > > > which
> > > > > > > > > > > > > > > > > don't use
> > > > > > > > > > > > > > > > > > > > `+`
> > > > > > > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > > > > > `clientInstanceIdVersion`
> > field.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > -Matthias
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > On 6/2/26 7:42 AM, Andrew
> > > > Schofield
> > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > > Following on from the
> > > > discussion
> > > > > > in the
> > > > > > > > > > > > > community,
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > difficulty
> > > > > > > > > > > > > > > > > > > > > > > > of trying to accommodate the
> > client
> > > > > > > > instance ID
> > > > > > > > > > > in a
> > > > > > > > > > > > > > > tagged
> > > > > > > > > > > > > > > > > field
> > > > > > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > > > > > > > acceptable complexity, I have
> > made
> > > > a
> > > > > > > > significant
> > > > > > > > > > > > > change
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > the KIP.
> > > > > > > > > > > > > > > > > > > > > > Now, it
> > > > > > > > > > > > > > > > > > > > > > > > introduces v3 of the request
> > header
> > > > > > > > containing
> > > > > > > > > > > the
> > > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > > > ID
> > > > > > > > > > > > > > > > > > > > > > as a
> > > > > > > > > > > > > > > > > > > > > > > > proper field.
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/KAFKA/KIP-1313*3A*Client*instance*ID*in*all*request*headers__;JSsrKysrKys!!Ayb5sqE7!pUZS25PuTKdhiqvTGcwDKbclqpG8dFOzw2Ax9WxVM6Sb09PVQ0gl1i0gjlr2_Krr66agbuVC2qLGgUcg7vrW$
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Please review and let me
> > know
> > > > what
> > > > > > you
> > > > > > > > think.
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > On 2026/05/28 21:51:01
> > > > "Matthias J.
> > > > > > > > Sax"
> > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > >> Thanks Andrew. I agree to
> > the
> > > > > > issue
> > > > > > > > that
> > > > > > > > > > > tagged
> > > > > > > > > > > > > > > fields
> > > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > > > > optional.
> > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > >> Nevertheless, I find the
> > > > proposed
> > > > > > > > > > > compatibility
> > > > > > > > > > > > > > > > > protocol too
> > > > > > > > > > > > > > > > > > > > > > complex
> > > > > > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > > > > > >> unnecessary, and would
> > still
> > > > > > prefer a
> > > > > > > > > > > version
> > > > > > > > > > > > > bump
> > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > `GetTelemetrySubscriptionsRequest/Reponse`
> > > > > > > > > > > to
> > > > > > > > > > > > > clean
> > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > > > > > > up. --
> > > > > > > > > > > > > > > > > > > > > > For
> > > > > > > > > > > > > > > > > > > > > > > > > >> `PushTelemetryRequest` the
> > > > > > argument
> > > > > > > > from
> > > > > > > > > > > above
> > > > > > > > > > > > > > > applies,
> > > > > > > > > > > > > > > > > so
> > > > > > > > > > > > > > > > > > > > > > leaving it
> > > > > > > > > > > > > > > > > > > > > > > > > >> untouched is ok.
> > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > >> I don't see why
> > > > > > > > > > > > > `GetTelemetrySubscriptionsRequest`
> > > > > > > > > > > > > > > > > would need
> > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > > > encode
> > > > > > > > > > > > > > > > > > > > > > > > > >> the `clientInstandId` in
> > it's
> > > > > > request
> > > > > > > > body.
> > > > > > > > > > > > > Given
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > > >> `clientInstanceId` is a
> > random
> > > > > > UUID,
> > > > > > > > the
> > > > > > > > > > > > > returned
> > > > > > > > > > > > > > > > > subscription
> > > > > > > > > > > > > > > > > > > > > > cannot
> > > > > > > > > > > > > > > > > > > > > > > > > >> really depend on it. So
> > why
> > > > would
> > > > > > we
> > > > > > > > need to
> > > > > > > > > > > > > send
> > > > > > > > > > > > > > > it to
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > broker?
> > > > > > > > > > > > > > > > > > > > > > > > > >> Right now, it's set to
> > ZERO
> > > > only
> > > > > > for
> > > > > > > > the
> > > > > > > > > > > > > purpose to
> > > > > > > > > > > > > > > get
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > broker to
> > > > > > > > > > > > > > > > > > > > > > > > > >> assign a new UUID. But it
> > has
> > > > > > nothing
> > > > > > > > to do
> > > > > > > > > > > > > with the
> > > > > > > > > > > > > > > > > actual
> > > > > > > > > > > > > > > > > > > > "what
> > > > > > > > > > > > > > > > > > > > > > > > > >> metrics should I send"
> > > > question.
> > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > >> To be fair, KIP-714 lists
> > > > > > > > > > > `client_instance_id`
> > > > > > > > > > > > > as a
> > > > > > > > > > > > > > > > > field that
> > > > > > > > > > > > > > > > > > > > > > can be
> > > > > > > > > > > > > > > > > > > > > > > > > >> used to define a
> > subscription.
> > > > > > But it
> > > > > > > > seems
> > > > > > > > > > > > > rather
> > > > > > > > > > > > > > > > > useless in
> > > > > > > > > > > > > > > > > > > > > > practice
> > > > > > > > > > > > > > > > > > > > > > > > > >> to me? I a user defines a
> > > > > > > > subscription, they
> > > > > > > > > > > > > cannot
> > > > > > > > > > > > > > > > > know the
> > > > > > > > > > > > > > > > > > > > UUID.
> > > > > > > > > > > > > > > > > > > > > > > > Thus,
> > > > > > > > > > > > > > > > > > > > > > > > > >> I think we should actually
> > > > drop
> > > > > > > > supporting
> > > > > > > > > > > > > > > > > > > > `client_instance_id`
> > > > > > > > > > > > > > > > > > > > > > as a
> > > > > > > > > > > > > > > > > > > > > > > > > >> "subscription matching
> > > > > > parameter"? Of
> > > > > > > > > > > course,
> > > > > > > > > > > > > there
> > > > > > > > > > > > > > > is a
> > > > > > > > > > > > > > > > > > > > backward
> > > > > > > > > > > > > > > > > > > > > > > > > >> compatibility question,
> > but I
> > > > > > think
> > > > > > > > we can
> > > > > > > > > > > > > address
> > > > > > > > > > > > > > > > > this: if
> > > > > > > > > > > > > > > > > > > > > > brokers
> > > > > > > > > > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > > > > > > > >> upgraded and they have an
> > > > existing
> > > > > > > > > > > > > > > `client_instance_id`
> > > > > > > > > > > > > > > > > based
> > > > > > > > > > > > > > > > > > > > > > > > > >> subscription defined, they
> > > > could
> > > > > > > > advertise
> > > > > > > > > > > to
> > > > > > > > > > > > > only
> > > > > > > > > > > > > > > > > support
> > > > > > > > > > > > > > > > > > > > v0, and
> > > > > > > > > > > > > > > > > > > > > > > > they
> > > > > > > > > > > > > > > > > > > > > > > > > >> should log a warning that
> > this
> > > > > > > > feature is
> > > > > > > > > > > > > > > deprecated.
> > > > > > > > > > > > > > > > > New
> > > > > > > > > > > > > > > > > > > > brokers
> > > > > > > > > > > > > > > > > > > > > > > > would
> > > > > > > > > > > > > > > > > > > > > > > > > >> also not allow to use
> > > > > > > > `client_instance_id`
> > > > > > > > > > > any
> > > > > > > > > > > > > > > longer to
> > > > > > > > > > > > > > > > > > > > define a
> > > > > > > > > > > > > > > > > > > > > > > > > >> subscription.
> > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > >> Similarly, for
> > > > > > > > > > > > > `GetTelemetrySubscriptionsResponse`,
> > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > only
> > > > > > > > > > > > > > > > > > > > need
> > > > > > > > > > > > > > > > > > > > > > > > > >> `clientInstanceId` if the
> > > > broker
> > > > > > > > computes
> > > > > > > > > > > the
> > > > > > > > > > > > > UUID.
> > > > > > > > > > > > > > > But
> > > > > > > > > > > > > > > > > if we
> > > > > > > > > > > > > > > > > > > > let
> > > > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > > >> client compute it, this
> > field
> > > > is
> > > > > > not
> > > > > > > > needed
> > > > > > > > > > > any
> > > > > > > > > > > > > > > longer.
> > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > >> -Matthias
> > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > >> On 5/28/26 1:21 AM, Andrew
> > > > > > Schofield
> > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > >>> Hi Jun,
> > > > > > > > > > > > > > > > > > > > > > > > > >>> Thanks for your response.
> > > > > > > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > > > > > > >>> JR24: I'll update the KIP
> > > > > > shortly.
> > > > > > > > Here's a
> > > > > > > > > > > > > > > summary.
> > > > > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > > > > > various
> > > > > > > > > > > > > > > > > > > > > > > > modern group protocol heartbeat
> > > > > > requests
> > > > > > > > encode
> > > > > > > > > > > the
> > > > > > > > > > > > > > > member
> > > > > > > > > > > > > > > > > ID as a
> > > > > > > > > > > > > > > > > > > > > > string
> > > > > > > > > > > > > > > > > > > > > > > > for historical reasons, even
> > though
> > > > > > it's in
> > > > > > > > > > > practice
> > > > > > > > > > > > > a
> > > > > > > > > > > > > > > UUID.
> > > > > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > > > > > Apache
> > > > > > > > > > > > > > > > > > > > > > > > Kafka Java client happens to
> > use
> > > > > > > > > > > > > > > > > org.apache.kafka.common.Uuid to
> > > > > > > > > > > > > > > > > > > > > > create the
> > > > > > > > > > > > > > > > > > > > > > > > member ID and convert it into a
> > > > string.
> > > > > > > > This
> > > > > > > > > > > means
> > > > > > > > > > > > > that
> > > > > > > > > > > > > > > when
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > clientInstanceId is converted
> > into
> > > > a
> > > > > > > > string, its
> > > > > > > > > > > > > encoding
> > > > > > > > > > > > > > > > > matches
> > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > member ID and it all lines up.
> > > > However,
> > > > > > > > there are
> > > > > > > > > > > > > other
> > > > > > > > > > > > > > > ways
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > encode
> > > > > > > > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > > > > > > > UUID into a string and I know
> > for a
> > > > > > fact
> > > > > > > > that the
> > > > > > > > > > > > > > > librdkafka
> > > > > > > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > > > > > > does it
> > > > > > > > > > > > > > > > > > > > > > > > differently.
> > > > > > > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > > > > > > >>> Thanks,
> > > > > > > > > > > > > > > > > > > > > > > > > >>> Andrew
> > > > > > > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > > > > > > >>> On 2026/05/27 17:11:25
> > Jun
> > > > Rao
> > > > > > via
> > > > > > > > dev
> > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > >>>> Hi, Andrew,
> > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > >>>> Thanks for the reply.
> > One
> > > > more
> > > > > > > > comment.
> > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > >>>> JR24. "The alignment of
> > > > other
> > > > > > > > identifiers
> > > > > > > > > > > is
> > > > > > > > > > > > > by
> > > > > > > > > > > > > > > > > convention
> > > > > > > > > > > > > > > > > > > > (and
> > > > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > Java
> > > > > > > > > > > > > > > > > > > > > > > > > >>>> client will follow the
> > > > > > convention)
> > > > > > > > rather
> > > > > > > > > > > than
> > > > > > > > > > > > > > > > > mandate."
> > > > > > > > > > > > > > > > > > > > Could
> > > > > > > > > > > > > > > > > > > > > > you
> > > > > > > > > > > > > > > > > > > > > > > > describe
> > > > > > > > > > > > > > > > > > > > > > > > > >>>> the convention to
> > convert a
> > > > > > > > > > > clientInstanceId
> > > > > > > > > > > > > > > (UUID)
> > > > > > > > > > > > > > > > > to a
> > > > > > > > > > > > > > > > > > > > > > memberId
> > > > > > > > > > > > > > > > > > > > > > > > (String)?
> > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > >>>> Jun
> > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > >>>> On Tue, May 19, 2026 at
> > > > 2:36 AM
> > > > > > > > Andrew
> > > > > > > > > > > > > Schofield <
> > > > > > > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > >>>>> 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 <
> > > > > > > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > > >>>>>> 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 <
> > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>
> > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> 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 <
> > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>
> > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> 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
> > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> 

Re: [DISCUSS] KIP-1313: Client instance ID in all request headers

[Jun Rao via dev <de...@kafka.apache.org>]

Hi, Andrew,

Thanks for the reply.

JR39. For clientInstanceID, we have: "If a client specifies a reserved
client instance ID (zero or one), the request will be rejected with error
code INVALID_REQUEST ."
For clientId, we have: "After this KIP, the broker will assume that the
client ID from the initial request applies to all subsequent requests
on a connection,
and it will ignore the client ID specified on any subsequent requests."
Could we make the behavior consistent between these two?

Jun


On Tue, Aug 4, 2026 at 1:05 PM Andrew Schofield <sc...@apache.org>
wrote:

> Hi Jun,
> Thanks for the reply.
>
> JR37: It had escaped me that ClientInstanceId is a tagged field, so you're
> absolutely right. (I am not an AI.) I'll update the KIP.
>
> Thanks,
> Andrew
>
> On 2026/08/04 18:24:19 Jun Rao via dev wrote:
> > Hi, Andrew,
> >
> > Thanks for the reply.
> >
> > JR37. UUID is 16 bytes. If it's omitted in subsequent requests, we save
> 16
> > bytes, right?
> >
> > Jun
> >
> >
> >
> > On Tue, Aug 4, 2026 at 5:47 AM Andrew Schofield <sc...@apache.org>
> > wrote:
> >
> > > Hi Jun,
> > > Thanks for your reply.
> > >
> > > JR37: Unlike with clientId where space is saved by not transmitting it
> on
> > > every request, there's nothing to be gained by omitting
> clientInstanceId on
> > > later requests. I prefer to leave it as is.
> > >
> > > JR38: OK, I've updated those paragraphs in the KIP to exclude the
> reserved
> > > UUIDs.
> > >
> > > Thanks,
> > > Andrew
> > >
> > > On 2026/08/03 20:23:39 Jun Rao via dev wrote:
> > > > Hi, Andrew,
> > > >
> > > > Thanks for the reply.
> > > >
> > > > JR37. Will it be better to require ClientInstanceId only on the first
> > > > request, to be consistent with clientId?
> > > >
> > > > JR38. "must specify a non-zero client instance ID". one_uuid is also
> a
> > > > reserved one in the Uuid class. Should we exclude that one too?
> > > >
> > > > Jun
> > > >
> > > > On Fri, Jul 31, 2026 at 9:10 AM Andrew Schofield <
> schofielaj@apache.org>
> > > > wrote:
> > > >
> > > > > Hi Jun,
> > > > > Thanks for the reply and sorry for the delay. Lots of 4.4 stuff
> got in
> > > the
> > > > > way.
> > > > >
> > > > > JR34: EligibleLeaderReplicasVersion and KRaftVersion also use
> > > ApiVersion
> > > > > to negotiate the RPC versions. I do not believe we need to bump up
> > > other
> > > > > feature versions as a result of the RPC version bumps in this KIP.
> > > > >
> > > > > JR35: Yes, good catch. In order to handle client ID-based quotas
> for
> > > > > forwarded requests, it will be necessary to populate the client ID
> in
> > > the
> > > > > forwarded request header. KIP updated.
> > > > >
> > > > > JR36: I hadn't considered MV to be a feature version, but I
> understand.
> > > > > KIP updated.
> > > > >
> > > > > Thanks,
> > > > > Andrew
> > > > >
> > > > > On 2026/06/29 16:23:09 Jun Rao via dev wrote:
> > > > > > Hi, Andrew,
> > > > > >
> > > > > > Thanks for the reply.
> > > > > >
> > > > > > JR34. Transaction coordinator uses ApiVersion to negotiate the
> PRC
> > > > > > versions. Therefore, if there is no functional change, there is
> no
> > > need
> > > > > to
> > > > > > bump the TV version. I am not sure about
> > > EligibleLeaderReplicasVersion
> > > > > > and KRaftVersion.
> > > > > > It would be useful to have the experts chime in.
> > > > > >
> > > > > > JR35. Envelope/forwarding interaction: When a broker forwards a
> > > client
> > > > > > request to the controller via EnvelopeUtils
> > > > > (parseForwardedRequestHeader),
> > > > > > the inner header may have its clientId optimized to null. Some
> quota
> > > > > > enforcement (e.g. controller mutation) may depend on the non-null
> > > > > clientId.
> > > > > > The per-connection caching occurs on the original client↔broker
> > > > > connection, not
> > > > > > the broker↔controller one. Should the forwarded request preserve
> the
> > > > > > non-null resolved (cached) client.id?
> > > > > >
> > > > > > JR36. "This KIP does not need to introduce any feature version
> > > bumps."
> > > > > This
> > > > > > is not very accurate since MV is a feature version and is bumped.
> > > > > >
> > > > > > Jun
> > > > > >
> > > > > >
> > > > > > On Fri, Jun 26, 2026 at 12:42 AM Andrew Schofield <
> > > schofielaj@apache.org
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Jun,
> > > > > > > I've updated the KIP.
> > > > > > >
> > > > > > > JS34: I don't believe that we need to introduce any new feature
> > > > > versions
> > > > > > > for this KIP. For example, we do not need a new ShareVersion
> since
> > > that
> > > > > > > enabled share groups (SV_1) and controls the versioning of the
> > > records
> > > > > on
> > > > > > > the internal topics (SV_2). I think the same applies for the
> > > others. I
> > > > > > > understand GroupVersion and StreamsVersion, and I think they
> > > follow the
> > > > > > > same reasoning as ShareVersion. I don't know
> TransactionVersion or
> > > > > > > EligibleLeaderReplicasVersion, so let me know whether those are
> > > > > different
> > > > > > > in this regard.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Andrew
> > > > > > >
> > > > > > > On 2026/06/25 21:32:27 Andrew Schofield wrote:
> > > > > > > > Hi Jun,
> > > > > > > > Thanks for the reply.
> > > > > > > >
> > > > > > > > JR27: Yes, makes sense. So request header v3 is
> binary-compatible
> > > > > with
> > > > > > > request header v2.
> > > > > > > >
> > > > > > > > JS34: Yes, I think so.
> > > > > > > >
> > > > > > > > I'll update the KIP tomorrow morning.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Andrew
> > > > > > > >
> > > > > > > > On 2026/06/25 20:23:57 Jun Rao via dev wrote:
> > > > > > > > > Hi, Andrew,
> > > > > > > > >
> > > > > > > > > Thanks for the reply.
> > > > > > > > >
> > > > > > > > > JR27. I was thinking of the following, which is slightly
> > > different
> > > > > from
> > > > > > > > > what you described.
> > > > > > > > > * Bump RequestHeader to v3, and introduce ClientInstanceId
> as a
> > > > > tagged
> > > > > > > > > field for versions 3+ and change the semantic of the
> existing
> > > field
> > > > > > > > > clientId (only need to be populated by the first request).
> > > > > > > > > * Bump the request versions for all RPCs including
> ApiVersion
> > > and
> > > > > map
> > > > > > > to
> > > > > > > > > the new version to use v3 of RequestHeader.
> > > > > > > > > * On the server side, when a new request version is seen,
> we
> > > > > enforce
> > > > > > > the
> > > > > > > > > presence of ClientInstanceId and reject the request if it
> is
> > > > > missing.
> > > > > > > > > Essentially, treat it as a required field. We also cache
> the
> > > > > clientId
> > > > > > > from
> > > > > > > > > the first request and ignore it from subsequent ones.
> > > > > > > > > * We would introduce OffsetDelete v1 as the first flexible
> > > version
> > > > > so
> > > > > > > that
> > > > > > > > > it uses the v3 request header.
> > > > > > > > > * We would update PushTelemetry and
> GetTelemetrySubscriptions
> > > as
> > > > > > > described
> > > > > > > > > in the KIP and the ClientInstanceId would move to the
> request
> > > > > header.
> > > > > > > > >
> > > > > > > > > In the future, if we want to add a new truly optional
> field to
> > > > > > > > > RequestHeader, we can continue adding it as a tagged field
> > > without
> > > > > > > bumping
> > > > > > > > > up the request version. To add a required field, we will
> add
> > > it as
> > > > > a
> > > > > > > tagged
> > > > > > > > > field but force a version bump to all requests.
> > > > > > > > >
> > > > > > > > > The benefit of this approach is that (1) it's compatible
> with
> > > the
> > > > > > > format of
> > > > > > > > > the old request header; (2) it avoids duplicating new
> fields;
> > > and
> > > > > (3)
> > > > > > > there
> > > > > > > > > is no constraint on deprecating the old request header.
> It's
> > > > > slightly
> > > > > > > weird
> > > > > > > > > to bump up the version when adding a tagged field. But it
> still
> > > > > seems
> > > > > > > > > better than the alternatives.
> > > > > > > > >
> > > > > > > > > JR34. Since we now have different feature versions gating
> > > different
> > > > > > > RPCs,
> > > > > > > > > should we bump up GV, TV, etc., too?
> > > > > > > > >
> > > > > > > > > Jun
> > > > > > > > >
> > > > > > > > > On Thu, Jun 25, 2026 at 10:37 AM Andrew Schofield <
> > > > > > > schofielaj@apache.org>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi Jun,
> > > > > > > > > > Thanks for the reply.
> > > > > > > > > >
> > > > > > > > > > JR27.1: What if we want to add non-optional fields to the
> > > request
> > > > > > > header
> > > > > > > > > > in the future? I think that such fields would be by
> > > definition
> > > > > future
> > > > > > > > > > fields which would not be understood by existing
> brokers. For
> > > > > > > serialization
> > > > > > > > > > reasons, I think we would use version 2+ tagged fields
> and
> > > the
> > > > > > > requirement
> > > > > > > > > > for non-optionality would be enforced by code, rather
> than
> > > by the
> > > > > > > protocol
> > > > > > > > > > schema. This avoids the field duplication.
> > > > > > > > > >
> > > > > > > > > > JR27.2: Yes, I don't like it, but when we inevitably do
> > > another
> > > > > > > KIP-896 to
> > > > > > > > > > remove support for ancient parts of the protocol, it's
> going
> > > to
> > > > > be
> > > > > > > another
> > > > > > > > > > KIP. That's all I meant.
> > > > > > > > > >
> > > > > > > > > > If I understand your proposal correctly compared with the
> > > > > existing
> > > > > > > KIP
> > > > > > > > > > text, it would look like this:
> > > > > > > > > > * Remove RequestHeader v3, and introduce
> ClientInstanceId as
> > > a
> > > > > tagged
> > > > > > > > > > field for versions 2+.
> > > > > > > > > > * Bump the request versions for all RPCs. We'd update the
> > > request
> > > > > > > JSON
> > > > > > > > > > schemas with something like "ClientInstanceIdVersions":
> "X+".
> > > > > This
> > > > > > > would
> > > > > > > > > > mean that the request would only be properly formed if it
> > > had the
> > > > > > > > > > ClientInstanceId present, and would also mean that
> ClientId
> > > > > could be
> > > > > > > null
> > > > > > > > > > for non-initial requests on each connection.
> > > > > > > > > > * We would create ApiVersions v6, simply as a matter of
> the
> > > > > bumping
> > > > > > > of
> > > > > > > > > > request versions for all RPCs, but its schema would be
> > > unchanged
> > > > > > > from v5.
> > > > > > > > > > * We would introduce OffsetDelete v1 as the first
> flexible
> > > > > version
> > > > > > > so that
> > > > > > > > > > it uses the v2 request header.
> > > > > > > > > > * We would update PushTelemetry and
> > > GetTelemetrySubscriptions as
> > > > > > > described
> > > > > > > > > > in the KIP and the ClientInstanceId would move to the
> request
> > > > > header.
> > > > > > > > > >
> > > > > > > > > > I think that works roughly the same as what we have
> today. I
> > > > > don't
> > > > > > > really
> > > > > > > > > > like the mandatory nature of the tagged field, but then I
> > > don't
> > > > > > > really like
> > > > > > > > > > the way that ApiVersions is pegged on a historical
> request
> > > header
> > > > > > > version.
> > > > > > > > > >
> > > > > > > > > > Do I have this correct? If so, I can update the KIP
> > > accordingly.
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > Andrew
> > > > > > > > > >
> > > > > > > > > > On 2026/06/24 23:40:06 Jun Rao via dev wrote:
> > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > >
> > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > >
> > > > > > > > > > > JR27.1 What if we want to add non-optional fields to
> the
> > > > > request
> > > > > > > header
> > > > > > > > > > in
> > > > > > > > > > > the future? The choice I see is duplicating the field
> in
> > > the
> > > > > new
> > > > > > > request
> > > > > > > > > > > header and the new ApiVersion request. But it's not
> very
> > > clean.
> > > > > > > > > > > JR27.2 Requiring a major version API compatibility KIP
> is
> > > also
> > > > > a
> > > > > > > bit
> > > > > > > > > > > awkward.
> > > > > > > > > > >
> > > > > > > > > > > Here is yet another proposal. We add the
> ClientInstanceId
> > > to
> > > > > the
> > > > > > > request
> > > > > > > > > > > header as a tagged field and also bump up all request
> > > versions.
> > > > > > > This
> > > > > > > > > > avoids
> > > > > > > > > > > the header compatibility issue in SocketServer. The
> > > bumped-up
> > > > > > > version
> > > > > > > > > > > signals that the new field is actually required. On the
> > > server
> > > > > > > side, when
> > > > > > > > > > > receiving the new version of a request, we verify that
> the
> > > > > > > > > > ClientInstanceId
> > > > > > > > > > > field exists. If it's not present, we reject the
> request.
> > > This
> > > > > > > will be
> > > > > > > > > > the
> > > > > > > > > > > convention for adding future required fields to the
> header.
> > > > > > > Compared to
> > > > > > > > > > the
> > > > > > > > > > > current proposal, this avoids duplicating the field
> between
> > > > > request
> > > > > > > > > > header
> > > > > > > > > > > and ApiVersionRequest, and it provides a path for
> > > deprecating
> > > > > the
> > > > > > > older
> > > > > > > > > > > version of the request header. What do you think?
> > > > > > > > > > >
> > > > > > > > > > > Jun
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Jun 24, 2026 at 2:15 AM Andrew Schofield <
> > > > > > > schofielaj@apache.org>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > >
> > > > > > > > > > > > JR27: Yes, I enhanced that section of the KIP.
> > > > > > > > > > > > JR27.1: This KIP was unusual because we wanted to
> add a
> > > > > concept
> > > > > > > which
> > > > > > > > > > > > existed in the KIP-714 RPCs to the request header,
> > > > > complicating
> > > > > > > the
> > > > > > > > > > > > behavior of those RPCs, AND we wanted to change the
> > > handling
> > > > > of
> > > > > > > client
> > > > > > > > > > ID
> > > > > > > > > > > > without breaking older brokers. If we simply wanted
> to
> > > add a
> > > > > > > brand new
> > > > > > > > > > > > field to the request header, we can do it as a tagged
> > > field
> > > > > in
> > > > > > > request
> > > > > > > > > > > > header versions 2+.
> > > > > > > > > > > > JR27.2: Covered this too. We'd need a major version
> API
> > > > > > > compatibility
> > > > > > > > > > KIP.
> > > > > > > > > > > >
> > > > > > > > > > > > JR31: Yes. KIP updated.
> > > > > > > > > > > >
> > > > > > > > > > > > JR32: Yes. This is a minor inconvenience I feel. KIP
> > > updated.
> > > > > > > > > > > >
> > > > > > > > > > > > JR33: I don't see the value of a string comparison
> here.
> > > > > > > Personally,
> > > > > > > > > > I'm
> > > > > > > > > > > > happy with "assume".
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks,
> > > > > > > > > > > > Andrew
> > > > > > > > > > > >
> > > > > > > > > > > > On 2026/06/23 22:52:15 Jun Rao via dev wrote:
> > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > > >
> > > > > > > > > > > > > JR27. The code that changed the request header
> parsing
> > > was
> > > > > > > > > > introduced in
> > > > > > > > > > > > > 2019 (
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://urldefense.com/v3/__https://github.com/apache/kafka/pull/7372__;!!Ayb5sqE7!scbWbTEEm2o-Y3MBGi829H2cpMWPRyrF9g2CW3lmRHyRmgBU2MyoRif2mFJpnfmvQ2x7fF4LrAJXdwH86ERR$
> > > > > > > > > > > > ). I agree that fixing it
> > > > > > > > > > > > > now is too late. We should document the path
> forward
> > > for
> > > > > > > ApiVersion.
> > > > > > > > > > > > Could
> > > > > > > > > > > > > we answer at least the following questions in the
> > > > > > > Compatibility,
> > > > > > > > > > > > > Deprecation, and Migration Plan section?
> > > > > > > > > > > > > JR27.1 What happens to ApiVersion if we change the
> > > request
> > > > > > > header in
> > > > > > > > > > the
> > > > > > > > > > > > > future?
> > > > > > > > > > > > > JR27.2 What happens if we ever want to deprecate
> v2 of
> > > the
> > > > > > > request
> > > > > > > > > > > > header?
> > > > > > > > > > > > >
> > > > > > > > > > > > > JR28. The new MV needs to be covered in the
> > > Compatibility,
> > > > > > > > > > Deprecation,
> > > > > > > > > > > > and
> > > > > > > > > > > > > Migration Plan section.
> > > > > > > > > > > > >
> > > > > > > > > > > > > JR31. "If a connection uses the v3 request header
> in
> > > its
> > > > > first
> > > > > > > > > > request,
> > > > > > > > > > > > it
> > > > > > > > > > > > > must specify a non-zero client instance ID and it
> must
> > > > > specify
> > > > > > > the
> > > > > > > > > > same
> > > > > > > > > > > > > client instance ID for all subsequent requests."
> > > > > > > > > > > > > Do we do the same if the first request is v6 of
> > > ApiVersion?
> > > > > > > > > > > > >
> > > > > > > > > > > > > JR32. "For subsequent requests using an earlier
> > > version of
> > > > > the
> > > > > > > > > > request
> > > > > > > > > > > > > header, the client sends the client ID". This means
> > > that
> > > > > > > subsequent
> > > > > > > > > > > > > ApiVersion V6 requests will carry the non-null
> clientID
> > > > > > > > > > unnecessarily.
> > > > > > > > > > > > >
> > > > > > > > > > > > > JR33. "After this KIP, the broker will assume that
> the
> > > > > client
> > > > > > > ID
> > > > > > > > > > from the
> > > > > > > > > > > > > initial request applies to all subsequent requests
> on a
> > > > > > > connection,
> > > > > > > > > > and
> > > > > > > > > > > > it
> > > > > > > > > > > > > will ignore the client ID specified on any
> subsequent
> > > > > > > requests."
> > > > > > > > > > > > > Should the broker verify that the clientId from
> > > subsequent
> > > > > > > request
> > > > > > > > > > match
> > > > > > > > > > > > > the first cached one, if not null?
> > > > > > > > > > > > >
> > > > > > > > > > > > >  Jun
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, Jun 23, 2026 at 6:05 AM Andrew Schofield <
> > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > Thanks for your reply.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > JR27: Unfortunately, I don't think this is
> > > acceptable. We
> > > > > > > would be
> > > > > > > > > > > > saying
> > > > > > > > > > > > > > that AK 4.5 clients can only connect to AK 4.5 or
> > > later
> > > > > > > brokers,
> > > > > > > > > > and
> > > > > > > > > > > > that
> > > > > > > > > > > > > > we'd create patch release for AK 4.0.x to AK
> 4.4.x.
> > > so
> > > > > AK 4.5
> > > > > > > > > > clients
> > > > > > > > > > > > could
> > > > > > > > > > > > > > connect to those too. We'd be preventing
> connection
> > > to
> > > > > AK 3.x
> > > > > > > > > > brokers
> > > > > > > > > > > > by AK
> > > > > > > > > > > > > > 4.5 clients. I don't see how we can break
> > > compatibility
> > > > > in a
> > > > > > > minor
> > > > > > > > > > > > release.
> > > > > > > > > > > > > > Here's the existing compatibility table:
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://urldefense.com/v3/__https://kafka.apache.org/41/getting-started/compatibility/__;!!Ayb5sqE7!ppWU_jI9f7EY9DYwcbiOESSBG2TmPn9CHfLnVM5TaIMwWqHUbUbIiGre1GGKMr-HmelQlyP6ibUSyORCAgte$
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > JR29: OK, makes sense to me.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On 2026/06/22 21:50:43 Jun Rao via dev wrote:
> > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR27. I am not sure I like the approach of
> pinning
> > > the
> > > > > > > header to
> > > > > > > > > > v2
> > > > > > > > > > > > for
> > > > > > > > > > > > > > > ApiVersionsRequest. This means that in the
> future,
> > > each
> > > > > > > change
> > > > > > > > > > to the
> > > > > > > > > > > > > > > request header must be duplicated in the
> request
> > > > > itself.
> > > > > > > Here is
> > > > > > > > > > an
> > > > > > > > > > > > > > > alternative. Note that to detect an unsupported
> > > > > > > > > > ApiVersionRequest, we
> > > > > > > > > > > > > > don't
> > > > > > > > > > > > > > > need to parse the full v2 request header.
> Parsing
> > > the
> > > > > > > first two
> > > > > > > > > > > > fields
> > > > > > > > > > > > > > > ApiKey and ApiVersion is enough. So, we could
> > > patch all
> > > > > > > the 4.x
> > > > > > > > > > > > releases
> > > > > > > > > > > > > > > with a change that short-circuits parsing the
> full
> > > > > request
> > > > > > > header
> > > > > > > > > > > > based
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > the first two fields. Then, we recommend
> upgrading
> > > > > from the
> > > > > > > > > > latest
> > > > > > > > > > > > 4.x
> > > > > > > > > > > > > > > releases to future releases. This way, we can
> > > still let
> > > > > > > > > > > > > > ApiVersionsRequest
> > > > > > > > > > > > > > > depend on the request header for current and
> future
> > > > > > > changes.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR29. The simplest thing is to upgrade the
> KRaft
> > > RPCs
> > > > > too
> > > > > > > to be
> > > > > > > > > > > > > > consistent.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Sat, Jun 20, 2026 at 3:38 AM Andrew
> Schofield <
> > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > Thanks for these insightful comments. I did
> > > > > prototype the
> > > > > > > > > > earlier
> > > > > > > > > > > > v2
> > > > > > > > > > > > > > > > request header with tagged fields variant. I
> > > have now
> > > > > > > > > > prototyped
> > > > > > > > > > > > the v3
> > > > > > > > > > > > > > > > request header variant.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > JR27: You were of course entirely correct
> that a
> > > new
> > > > > > > version of
> > > > > > > > > > > > > > > > ApiVersions request cannot use a request
> header
> > > > > which is
> > > > > > > not
> > > > > > > > > > > > > > > > binary-compatible with what has gone before.
> As a
> > > > > > > result, I
> > > > > > > > > > have
> > > > > > > > > > > > > > introduced
> > > > > > > > > > > > > > > > a new version of ApiVersions request which
> > > includes
> > > > > > > > > > > > ClientInstanceId
> > > > > > > > > > > > > > in the
> > > > > > > > > > > > > > > > request body but continues to use the v2
> request
> > > > > header.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > JR28: Yes, we need a new metadata version,
> which
> > > is
> > > > > > > > > > provisionally
> > > > > > > > > > > > > > > > IBP_4_5_IV0. I'll update the KIP with the
> final
> > > value
> > > > > > > when it
> > > > > > > > > > is
> > > > > > > > > > > > > > assigned.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > JR29: I don't have any strong feelings on
> this. I
> > > > > > > suppose for
> > > > > > > > > > each
> > > > > > > > > > > > > > inter
> > > > > > > > > > > > > > > > broker RPC version that is bumped, we need to
> > > > > introduce
> > > > > > > an MV
> > > > > > > > > > > > check. We
> > > > > > > > > > > > > > > > cannot avoid this for RPCs which are also
> used by
> > > > > > > clients such
> > > > > > > > > > as
> > > > > > > > > > > > > > Fetch.
> > > > > > > > > > > > > > > > For purely inter-broker RPCs, we could just
> > > exempt
> > > > > them
> > > > > > > from
> > > > > > > > > > the
> > > > > > > > > > > > > > version
> > > > > > > > > > > > > > > > bump. What do you recommend here?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > JR30: Done. INVALID_REQUEST. I did consider
> > > > > permitting
> > > > > > > zero
> > > > > > > > > > client
> > > > > > > > > > > > > > > > instance ID for inter-broker connections,
> but I
> > > > > decided
> > > > > > > that I
> > > > > > > > > > > > > > preferred
> > > > > > > > > > > > > > > > not creating another rule.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On 2026/06/17 22:45:07 Andrew Schofield
> wrote:
> > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > JR27: I am familiar with KIP-511 and the
> > > oddness of
> > > > > > > > > > ApiVersions.
> > > > > > > > > > > > You
> > > > > > > > > > > > > > > > make an excellent point. I suspect that
> > > > > > > ApiVersionsRequest will
> > > > > > > > > > > > have
> > > > > > > > > > > > > > to be
> > > > > > > > > > > > > > > > limited to the v2 request header, just as it
> is
> > > > > > > restricted to
> > > > > > > > > > the
> > > > > > > > > > > > v0
> > > > > > > > > > > > > > > > response header.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I'll do some experimentation.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On 2026/06/17 17:35:17 Jun Rao via dev
> wrote:
> > > > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Thanks for the reply. A few more
> comments.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > JR27. It seems that we have a
> compatibility
> > > issue
> > > > > > > with
> > > > > > > > > > > > > > > > ApiVersionRequest v6
> > > > > > > > > > > > > > > > > > depending on RequestHeader v3. This
> happens
> > > when
> > > > > a
> > > > > > > new
> > > > > > > > > > client
> > > > > > > > > > > > > > issues
> > > > > > > > > > > > > > > > > > ApiVersionRequest v6 to an old broker
> (one
> > > that
> > > > > only
> > > > > > > > > > supports
> > > > > > > > > > > > > > > > > > ApiVersionRequest v5). The SocketServer
> in
> > > the
> > > > > > > broker will
> > > > > > > > > > > > first
> > > > > > > > > > > > > > try to
> > > > > > > > > > > > > > > > > > read the request header. It tries to
> find the
> > > > > header
> > > > > > > > > > version
> > > > > > > > > > > > from
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > request version. Since the broker doesn't
> > > know
> > > > > > > > > > > > ApiVersionRequest
> > > > > > > > > > > > > > v6, it
> > > > > > > > > > > > > > > > > > uses v2 to parse the request header.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > The v2's wire format for the request
> header
> > > is:
> > > > > > > ApiKey |
> > > > > > > > > > > > > > ApiVersion |
> > > > > > > > > > > > > > > > > > CorrelationId | ClientId |
> > > tagged-fields-varint
> > > > > > > > > > > > > > > > > > The v3's wire format for the request
> header
> > > is:
> > > > > > > ApiKey |
> > > > > > > > > > > > > > ApiVersion |
> > > > > > > > > > > > > > > > > > CorrelationId | ClientId |
> > > ClientInstanceId(16
> > > > > > > bytes) |
> > > > > > > > > > > > > > tagged-fields
> > > > > > > > > > > > > > > > varint
> > > > > > > > > > > > > > > > > > The first 4 fields are identical,
> allowing
> > > the
> > > > > > > broker to
> > > > > > > > > > parse
> > > > > > > > > > > > > > them.
> > > > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > > > broker then tries to read the
> > > > > tagged-fields-varint
> > > > > > > using
> > > > > > > > > > the
> > > > > > > > > > > > > > serialized
> > > > > > > > > > > > > > > > > > bytes intended for ClientInstanceId. This
> > > could
> > > > > lead
> > > > > > > to a
> > > > > > > > > > > > parsing
> > > > > > > > > > > > > > > > error and
> > > > > > > > > > > > > > > > > > raise an invalid request error. The
> broker
> > > will
> > > > > > > close the
> > > > > > > > > > > > > > connection
> > > > > > > > > > > > > > > > > > instead of sending a v0 response for
> > > > > > > ApiVersionRequest.
> > > > > > > > > > Then
> > > > > > > > > > > > the
> > > > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > > will never be able to detect supported
> API
> > > > > versions
> > > > > > > on the
> > > > > > > > > > old
> > > > > > > > > > > > > > broker.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > The same problem didn't exist when
> > > > > ApiVersionRequest
> > > > > > > > > > changed
> > > > > > > > > > > > from
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > v1
> > > > > > > > > > > > > > > > > > request header to v2 because the wire
> format
> > > for
> > > > > v1
> > > > > > > is a
> > > > > > > > > > > > prefix of
> > > > > > > > > > > > > > v2.
> > > > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > > > problem exists for this KIP because the
> wire
> > > > > format
> > > > > > > of v2
> > > > > > > > > > is no
> > > > > > > > > > > > > > longer
> > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > prefix of v3.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > JR28. Since we are bumping up the
> version of
> > > > > inter
> > > > > > > broker
> > > > > > > > > > > > > > requests, we
> > > > > > > > > > > > > > > > need
> > > > > > > > > > > > > > > > > > to gate them by introducing a new MV.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > JR29. Could you specify whether the
> version
> > > for
> > > > > > > KRaft PRCs
> > > > > > > > > > > > will be
> > > > > > > > > > > > > > > > bumped
> > > > > > > > > > > > > > > > > > too?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > JR30. "If a connection uses the v3
> request
> > > > > header in
> > > > > > > its
> > > > > > > > > > first
> > > > > > > > > > > > > > > > request, it
> > > > > > > > > > > > > > > > > > must specify a non-zero client instance
> ID"
> > > > > > > > > > > > > > > > > > Could we define the broker's behavior
> when a
> > > v3
> > > > > > > request
> > > > > > > > > > header
> > > > > > > > > > > > > > > > contains a 0
> > > > > > > > > > > > > > > > > > client instance ID?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Tue, Jun 16, 2026 at 1:25 AM Andrew
> > > Schofield
> > > > > <
> > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > JR26: Yes, I was considering open-ended
> > > version
> > > > > > > ranges.
> > > > > > > > > > I've
> > > > > > > > > > > > > > updated
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > KIP.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Now that we have a new request header
> > > version,
> > > > > I
> > > > > > > think
> > > > > > > > > > it's
> > > > > > > > > > > > safe
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > reintroduce the client ID optimisation.
> > > I've
> > > > > added
> > > > > > > that
> > > > > > > > > > into
> > > > > > > > > > > > the
> > > > > > > > > > > > > > KIP
> > > > > > > > > > > > > > > > also.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Let me know what you think.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On 2026/06/15 17:46:00 Jun Rao via dev
> > > wrote:
> > > > > > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Thanks for the reply. Just a minor
> > > comment.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > JR26. "The keys of the map are either
> > > single
> > > > > > > versions
> > > > > > > > > > like
> > > > > > > > > > > > "0"
> > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > closed
> > > > > > > > > > > > > > > > > > > > version ranges like "1-2"."
> > > > > > > > > > > > > > > > > > > > It will be useful to support
> open-ended
> > > > > > > versions. That
> > > > > > > > > > way,
> > > > > > > > > > > > > > "3":
> > > > > > > > > > > > > > > > "3"
> > > > > > > > > > > > > > > > > > > could
> > > > > > > > > > > > > > > > > > > > be "3+": "3". This part won't need to
> > > change
> > > > > in
> > > > > > > the
> > > > > > > > > > future
> > > > > > > > > > > > > > when we
> > > > > > > > > > > > > > > > bump
> > > > > > > > > > > > > > > > > > > up
> > > > > > > > > > > > > > > > > > > > the request version without changing
> the
> > > > > header.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Fri, Jun 12, 2026 at 2:12 PM
> Andrew
> > > > > Schofield
> > > > > > > <
> > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > JR25: I agree. I've changed to a
> > > > > > > headerVersions map
> > > > > > > > > > in
> > > > > > > > > > > > both
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > request
> > > > > > > > > > > > > > > > > > > > > and response schemas.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Let me know what you think.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On 2026/06/12 03:39:39 Jun Rao via
> dev
> > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Thanks for the updated KIP.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > JR25. I have some concerns about
> > > adding
> > > > > the
> > > > > > > > > > > > > > > > clientInstanceIdVersions
> > > > > > > > > > > > > > > > > > > > > field
> > > > > > > > > > > > > > > > > > > > > > to the schema. First of all, it
> only
> > > > > applies
> > > > > > > to
> > > > > > > > > > > > requests,
> > > > > > > > > > > > > > but
> > > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > > > > > > responses. So, it's a bit weird
> to
> > > add
> > > > > it to
> > > > > > > the
> > > > > > > > > > > > general
> > > > > > > > > > > > > > > > schema.
> > > > > > > > > > > > > > > > > > > > > Secondly,
> > > > > > > > > > > > > > > > > > > > > > it's very specific to the new
> field
> > > > > added to
> > > > > > > the
> > > > > > > > > > > > request
> > > > > > > > > > > > > > > > header. If
> > > > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > > > change the request header again
> in
> > > the
> > > > > > > future, we
> > > > > > > > > > need
> > > > > > > > > > > > > > another
> > > > > > > > > > > > > > > > way
> > > > > > > > > > > > > > > > > > > to map
> > > > > > > > > > > > > > > > > > > > > > request versions to the new
> header
> > > > > version.
> > > > > > > > > > Ideally, we
> > > > > > > > > > > > > > should
> > > > > > > > > > > > > > > > have a
> > > > > > > > > > > > > > > > > > > > > > generic way to map request
> versions
> > > to
> > > > > all
> > > > > > > future
> > > > > > > > > > > > header
> > > > > > > > > > > > > > > > versions.
> > > > > > > > > > > > > > > > > > > One
> > > > > > > > > > > > > > > > > > > > > > possibility is to introduce a
> > > > > headerVersion
> > > > > > > field
> > > > > > > > > > in
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > schema.
> > > > > > > > > > > > > > > > > > > Then,
> > > > > > > > > > > > > > > > > > > > > each
> > > > > > > > > > > > > > > > > > > > > > request/response can use this
> field
> > > to
> > > > > map
> > > > > > > its
> > > > > > > > > > > > versions to
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > header
> > > > > > > > > > > > > > > > > > > > > > versions.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Tue, Jun 9, 2026 at 4:55 AM
> Andrew
> > > > > > > Schofield <
> > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Hi Matthias,
> > > > > > > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > I have change the version
> property
> > > for
> > > > > > > > > > introducing
> > > > > > > > > > > > client
> > > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > > ID
> > > > > > > > > > > > > > > > > > > > > into
> > > > > > > > > > > > > > > > > > > > > > > the request headers to be
> > > > > > > > > > `clientInstanceIdVersions`
> > > > > > > > > > > > > > which
> > > > > > > > > > > > > > > > is now
> > > > > > > > > > > > > > > > > > > an
> > > > > > > > > > > > > > > > > > > > > > > open-ended range, such as "3+",
> > > more
> > > > > > > closely
> > > > > > > > > > matching
> > > > > > > > > > > > > > what
> > > > > > > > > > > > > > > > we have
> > > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > > > flexible versions.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > I also added a change to the
> > > > > > > > > > > > > > > > RebalanceConsumer.clientInstanceId
> > > > > > > > > > > > > > > > > > > method
> > > > > > > > > > > > > > > > > > > > > > > introduced in KIP-1306.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > On 2026/06/03 18:31:06
> "Matthias J.
> > > > > Sax"
> > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > Thanks Andrew.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >  From a KIP-714 perspective,
> > > this is
> > > > > a
> > > > > > > great
> > > > > > > > > > > > change,
> > > > > > > > > > > > > > as it
> > > > > > > > > > > > > > > > make
> > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > new
> > > > > > > > > > > > > > > > > > > > > > > > RPCs and client/broker
> > > cross-version
> > > > > > > > > > compatibility
> > > > > > > > > > > > > > clean.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > One question about your
> > > > > `DeleteGroups`
> > > > > > > RPC
> > > > > > > > > > example.
> > > > > > > > > > > > > > Should
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > new
> > > > > > > > > > > > > > > > > > > > > > > > version of the RPC say
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > "clientInstanceIdVersion":
> > > "3+",
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > ie, 3+ instead of 3? Similar
> for
> > > > > other
> > > > > > > request,
> > > > > > > > > > > > which
> > > > > > > > > > > > > > > > don't use
> > > > > > > > > > > > > > > > > > > `+`
> > > > > > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > > > > `clientInstanceIdVersion`
> field.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > -Matthias
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > On 6/2/26 7:42 AM, Andrew
> > > Schofield
> > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > > Following on from the
> > > discussion
> > > > > in the
> > > > > > > > > > > > community,
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > difficulty
> > > > > > > > > > > > > > > > > > > > > > > of trying to accommodate the
> client
> > > > > > > instance ID
> > > > > > > > > > in a
> > > > > > > > > > > > > > tagged
> > > > > > > > > > > > > > > > field
> > > > > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > > > > > > acceptable complexity, I have
> made
> > > a
> > > > > > > significant
> > > > > > > > > > > > change
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > the KIP.
> > > > > > > > > > > > > > > > > > > > > Now, it
> > > > > > > > > > > > > > > > > > > > > > > introduces v3 of the request
> header
> > > > > > > containing
> > > > > > > > > > the
> > > > > > > > > > > > client
> > > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > > ID
> > > > > > > > > > > > > > > > > > > > > as a
> > > > > > > > > > > > > > > > > > > > > > > proper field.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > >
> > > > >
> > >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/KAFKA/KIP-1313*3A*Client*instance*ID*in*all*request*headers__;JSsrKysrKys!!Ayb5sqE7!pUZS25PuTKdhiqvTGcwDKbclqpG8dFOzw2Ax9WxVM6Sb09PVQ0gl1i0gjlr2_Krr66agbuVC2qLGgUcg7vrW$
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Please review and let me
> know
> > > what
> > > > > you
> > > > > > > think.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > On 2026/05/28 21:51:01
> > > "Matthias J.
> > > > > > > Sax"
> > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > >> Thanks Andrew. I agree to
> the
> > > > > issue
> > > > > > > that
> > > > > > > > > > tagged
> > > > > > > > > > > > > > fields
> > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > > > optional.
> > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > >> Nevertheless, I find the
> > > proposed
> > > > > > > > > > compatibility
> > > > > > > > > > > > > > > > protocol too
> > > > > > > > > > > > > > > > > > > > > complex
> > > > > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > > > > >> unnecessary, and would
> still
> > > > > prefer a
> > > > > > > > > > version
> > > > > > > > > > > > bump
> > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > `GetTelemetrySubscriptionsRequest/Reponse`
> > > > > > > > > > to
> > > > > > > > > > > > clean
> > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > > > > > up. --
> > > > > > > > > > > > > > > > > > > > > For
> > > > > > > > > > > > > > > > > > > > > > > > >> `PushTelemetryRequest` the
> > > > > argument
> > > > > > > from
> > > > > > > > > > above
> > > > > > > > > > > > > > applies,
> > > > > > > > > > > > > > > > so
> > > > > > > > > > > > > > > > > > > > > leaving it
> > > > > > > > > > > > > > > > > > > > > > > > >> untouched is ok.
> > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > >> I don't see why
> > > > > > > > > > > > `GetTelemetrySubscriptionsRequest`
> > > > > > > > > > > > > > > > would need
> > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > > encode
> > > > > > > > > > > > > > > > > > > > > > > > >> the `clientInstandId` in
> it's
> > > > > request
> > > > > > > body.
> > > > > > > > > > > > Given
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > >> `clientInstanceId` is a
> random
> > > > > UUID,
> > > > > > > the
> > > > > > > > > > > > returned
> > > > > > > > > > > > > > > > subscription
> > > > > > > > > > > > > > > > > > > > > cannot
> > > > > > > > > > > > > > > > > > > > > > > > >> really depend on it. So
> why
> > > would
> > > > > we
> > > > > > > need to
> > > > > > > > > > > > send
> > > > > > > > > > > > > > it to
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > broker?
> > > > > > > > > > > > > > > > > > > > > > > > >> Right now, it's set to
> ZERO
> > > only
> > > > > for
> > > > > > > the
> > > > > > > > > > > > purpose to
> > > > > > > > > > > > > > get
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > broker to
> > > > > > > > > > > > > > > > > > > > > > > > >> assign a new UUID. But it
> has
> > > > > nothing
> > > > > > > to do
> > > > > > > > > > > > with the
> > > > > > > > > > > > > > > > actual
> > > > > > > > > > > > > > > > > > > "what
> > > > > > > > > > > > > > > > > > > > > > > > >> metrics should I send"
> > > question.
> > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > >> To be fair, KIP-714 lists
> > > > > > > > > > `client_instance_id`
> > > > > > > > > > > > as a
> > > > > > > > > > > > > > > > field that
> > > > > > > > > > > > > > > > > > > > > can be
> > > > > > > > > > > > > > > > > > > > > > > > >> used to define a
> subscription.
> > > > > But it
> > > > > > > seems
> > > > > > > > > > > > rather
> > > > > > > > > > > > > > > > useless in
> > > > > > > > > > > > > > > > > > > > > practice
> > > > > > > > > > > > > > > > > > > > > > > > >> to me? I a user defines a
> > > > > > > subscription, they
> > > > > > > > > > > > cannot
> > > > > > > > > > > > > > > > know the
> > > > > > > > > > > > > > > > > > > UUID.
> > > > > > > > > > > > > > > > > > > > > > > Thus,
> > > > > > > > > > > > > > > > > > > > > > > > >> I think we should actually
> > > drop
> > > > > > > supporting
> > > > > > > > > > > > > > > > > > > `client_instance_id`
> > > > > > > > > > > > > > > > > > > > > as a
> > > > > > > > > > > > > > > > > > > > > > > > >> "subscription matching
> > > > > parameter"? Of
> > > > > > > > > > course,
> > > > > > > > > > > > there
> > > > > > > > > > > > > > is a
> > > > > > > > > > > > > > > > > > > backward
> > > > > > > > > > > > > > > > > > > > > > > > >> compatibility question,
> but I
> > > > > think
> > > > > > > we can
> > > > > > > > > > > > address
> > > > > > > > > > > > > > > > this: if
> > > > > > > > > > > > > > > > > > > > > brokers
> > > > > > > > > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > > > > > > >> upgraded and they have an
> > > existing
> > > > > > > > > > > > > > `client_instance_id`
> > > > > > > > > > > > > > > > based
> > > > > > > > > > > > > > > > > > > > > > > > >> subscription defined, they
> > > could
> > > > > > > advertise
> > > > > > > > > > to
> > > > > > > > > > > > only
> > > > > > > > > > > > > > > > support
> > > > > > > > > > > > > > > > > > > v0, and
> > > > > > > > > > > > > > > > > > > > > > > they
> > > > > > > > > > > > > > > > > > > > > > > > >> should log a warning that
> this
> > > > > > > feature is
> > > > > > > > > > > > > > deprecated.
> > > > > > > > > > > > > > > > New
> > > > > > > > > > > > > > > > > > > brokers
> > > > > > > > > > > > > > > > > > > > > > > would
> > > > > > > > > > > > > > > > > > > > > > > > >> also not allow to use
> > > > > > > `client_instance_id`
> > > > > > > > > > any
> > > > > > > > > > > > > > longer to
> > > > > > > > > > > > > > > > > > > define a
> > > > > > > > > > > > > > > > > > > > > > > > >> subscription.
> > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > >> Similarly, for
> > > > > > > > > > > > `GetTelemetrySubscriptionsResponse`,
> > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > only
> > > > > > > > > > > > > > > > > > > need
> > > > > > > > > > > > > > > > > > > > > > > > >> `clientInstanceId` if the
> > > broker
> > > > > > > computes
> > > > > > > > > > the
> > > > > > > > > > > > UUID.
> > > > > > > > > > > > > > But
> > > > > > > > > > > > > > > > if we
> > > > > > > > > > > > > > > > > > > let
> > > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > > >> client compute it, this
> field
> > > is
> > > > > not
> > > > > > > needed
> > > > > > > > > > any
> > > > > > > > > > > > > > longer.
> > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > >> -Matthias
> > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > >> On 5/28/26 1:21 AM, Andrew
> > > > > Schofield
> > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > >>> Hi Jun,
> > > > > > > > > > > > > > > > > > > > > > > > >>> Thanks for your response.
> > > > > > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > > > > > >>> JR24: I'll update the KIP
> > > > > shortly.
> > > > > > > Here's a
> > > > > > > > > > > > > > summary.
> > > > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > > > > various
> > > > > > > > > > > > > > > > > > > > > > > modern group protocol heartbeat
> > > > > requests
> > > > > > > encode
> > > > > > > > > > the
> > > > > > > > > > > > > > member
> > > > > > > > > > > > > > > > ID as a
> > > > > > > > > > > > > > > > > > > > > string
> > > > > > > > > > > > > > > > > > > > > > > for historical reasons, even
> though
> > > > > it's in
> > > > > > > > > > practice
> > > > > > > > > > > > a
> > > > > > > > > > > > > > UUID.
> > > > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > > > > Apache
> > > > > > > > > > > > > > > > > > > > > > > Kafka Java client happens to
> use
> > > > > > > > > > > > > > > > org.apache.kafka.common.Uuid to
> > > > > > > > > > > > > > > > > > > > > create the
> > > > > > > > > > > > > > > > > > > > > > > member ID and convert it into a
> > > string.
> > > > > > > This
> > > > > > > > > > means
> > > > > > > > > > > > that
> > > > > > > > > > > > > > when
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > clientInstanceId is converted
> into
> > > a
> > > > > > > string, its
> > > > > > > > > > > > encoding
> > > > > > > > > > > > > > > > matches
> > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > member ID and it all lines up.
> > > However,
> > > > > > > there are
> > > > > > > > > > > > other
> > > > > > > > > > > > > > ways
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > encode
> > > > > > > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > > > > > > UUID into a string and I know
> for a
> > > > > fact
> > > > > > > that the
> > > > > > > > > > > > > > librdkafka
> > > > > > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > > > > > does it
> > > > > > > > > > > > > > > > > > > > > > > differently.
> > > > > > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > > > > > >>> Thanks,
> > > > > > > > > > > > > > > > > > > > > > > > >>> Andrew
> > > > > > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > > > > > >>> On 2026/05/27 17:11:25
> Jun
> > > Rao
> > > > > via
> > > > > > > dev
> > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > >>>> Hi, Andrew,
> > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > >>>> Thanks for the reply.
> One
> > > more
> > > > > > > comment.
> > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > >>>> JR24. "The alignment of
> > > other
> > > > > > > identifiers
> > > > > > > > > > is
> > > > > > > > > > > > by
> > > > > > > > > > > > > > > > convention
> > > > > > > > > > > > > > > > > > > (and
> > > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > Java
> > > > > > > > > > > > > > > > > > > > > > > > >>>> client will follow the
> > > > > convention)
> > > > > > > rather
> > > > > > > > > > than
> > > > > > > > > > > > > > > > mandate."
> > > > > > > > > > > > > > > > > > > Could
> > > > > > > > > > > > > > > > > > > > > you
> > > > > > > > > > > > > > > > > > > > > > > describe
> > > > > > > > > > > > > > > > > > > > > > > > >>>> the convention to
> convert a
> > > > > > > > > > clientInstanceId
> > > > > > > > > > > > > > (UUID)
> > > > > > > > > > > > > > > > to a
> > > > > > > > > > > > > > > > > > > > > memberId
> > > > > > > > > > > > > > > > > > > > > > > (String)?
> > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > >>>> Jun
> > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > >>>> On Tue, May 19, 2026 at
> > > 2:36 AM
> > > > > > > Andrew
> > > > > > > > > > > > Schofield <
> > > > > > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > >>>>> 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 <
> > > > > > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > >>>>>> 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 <
> > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>
> schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> 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 <
> > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>
> schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> 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
> > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] KIP-1313: Client instance ID in all request headers

[Andrew Schofield <sc...@apache.org>]

Hi Jun,
Thanks for the reply.

JR37: It had escaped me that ClientInstanceId is a tagged field, so you're absolutely right. (I am not an AI.) I'll update the KIP.

Thanks,
Andrew

On 2026/08/04 18:24:19 Jun Rao via dev wrote:
> Hi, Andrew,
> 
> Thanks for the reply.
> 
> JR37. UUID is 16 bytes. If it's omitted in subsequent requests, we save 16
> bytes, right?
> 
> Jun
> 
> 
> 
> On Tue, Aug 4, 2026 at 5:47 AM Andrew Schofield <sc...@apache.org>
> wrote:
> 
> > Hi Jun,
> > Thanks for your reply.
> >
> > JR37: Unlike with clientId where space is saved by not transmitting it on
> > every request, there's nothing to be gained by omitting clientInstanceId on
> > later requests. I prefer to leave it as is.
> >
> > JR38: OK, I've updated those paragraphs in the KIP to exclude the reserved
> > UUIDs.
> >
> > Thanks,
> > Andrew
> >
> > On 2026/08/03 20:23:39 Jun Rao via dev wrote:
> > > Hi, Andrew,
> > >
> > > Thanks for the reply.
> > >
> > > JR37. Will it be better to require ClientInstanceId only on the first
> > > request, to be consistent with clientId?
> > >
> > > JR38. "must specify a non-zero client instance ID". one_uuid is also a
> > > reserved one in the Uuid class. Should we exclude that one too?
> > >
> > > Jun
> > >
> > > On Fri, Jul 31, 2026 at 9:10 AM Andrew Schofield <sc...@apache.org>
> > > wrote:
> > >
> > > > Hi Jun,
> > > > Thanks for the reply and sorry for the delay. Lots of 4.4 stuff got in
> > the
> > > > way.
> > > >
> > > > JR34: EligibleLeaderReplicasVersion and KRaftVersion also use
> > ApiVersion
> > > > to negotiate the RPC versions. I do not believe we need to bump up
> > other
> > > > feature versions as a result of the RPC version bumps in this KIP.
> > > >
> > > > JR35: Yes, good catch. In order to handle client ID-based quotas for
> > > > forwarded requests, it will be necessary to populate the client ID in
> > the
> > > > forwarded request header. KIP updated.
> > > >
> > > > JR36: I hadn't considered MV to be a feature version, but I understand.
> > > > KIP updated.
> > > >
> > > > Thanks,
> > > > Andrew
> > > >
> > > > On 2026/06/29 16:23:09 Jun Rao via dev wrote:
> > > > > Hi, Andrew,
> > > > >
> > > > > Thanks for the reply.
> > > > >
> > > > > JR34. Transaction coordinator uses ApiVersion to negotiate the PRC
> > > > > versions. Therefore, if there is no functional change, there is no
> > need
> > > > to
> > > > > bump the TV version. I am not sure about
> > EligibleLeaderReplicasVersion
> > > > > and KRaftVersion.
> > > > > It would be useful to have the experts chime in.
> > > > >
> > > > > JR35. Envelope/forwarding interaction: When a broker forwards a
> > client
> > > > > request to the controller via EnvelopeUtils
> > > > (parseForwardedRequestHeader),
> > > > > the inner header may have its clientId optimized to null. Some quota
> > > > > enforcement (e.g. controller mutation) may depend on the non-null
> > > > clientId.
> > > > > The per-connection caching occurs on the original client↔broker
> > > > connection, not
> > > > > the broker↔controller one. Should the forwarded request preserve the
> > > > > non-null resolved (cached) client.id?
> > > > >
> > > > > JR36. "This KIP does not need to introduce any feature version
> > bumps."
> > > > This
> > > > > is not very accurate since MV is a feature version and is bumped.
> > > > >
> > > > > Jun
> > > > >
> > > > >
> > > > > On Fri, Jun 26, 2026 at 12:42 AM Andrew Schofield <
> > schofielaj@apache.org
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Hi Jun,
> > > > > > I've updated the KIP.
> > > > > >
> > > > > > JS34: I don't believe that we need to introduce any new feature
> > > > versions
> > > > > > for this KIP. For example, we do not need a new ShareVersion since
> > that
> > > > > > enabled share groups (SV_1) and controls the versioning of the
> > records
> > > > on
> > > > > > the internal topics (SV_2). I think the same applies for the
> > others. I
> > > > > > understand GroupVersion and StreamsVersion, and I think they
> > follow the
> > > > > > same reasoning as ShareVersion. I don't know TransactionVersion or
> > > > > > EligibleLeaderReplicasVersion, so let me know whether those are
> > > > different
> > > > > > in this regard.
> > > > > >
> > > > > > Thanks,
> > > > > > Andrew
> > > > > >
> > > > > > On 2026/06/25 21:32:27 Andrew Schofield wrote:
> > > > > > > Hi Jun,
> > > > > > > Thanks for the reply.
> > > > > > >
> > > > > > > JR27: Yes, makes sense. So request header v3 is binary-compatible
> > > > with
> > > > > > request header v2.
> > > > > > >
> > > > > > > JS34: Yes, I think so.
> > > > > > >
> > > > > > > I'll update the KIP tomorrow morning.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Andrew
> > > > > > >
> > > > > > > On 2026/06/25 20:23:57 Jun Rao via dev wrote:
> > > > > > > > Hi, Andrew,
> > > > > > > >
> > > > > > > > Thanks for the reply.
> > > > > > > >
> > > > > > > > JR27. I was thinking of the following, which is slightly
> > different
> > > > from
> > > > > > > > what you described.
> > > > > > > > * Bump RequestHeader to v3, and introduce ClientInstanceId as a
> > > > tagged
> > > > > > > > field for versions 3+ and change the semantic of the existing
> > field
> > > > > > > > clientId (only need to be populated by the first request).
> > > > > > > > * Bump the request versions for all RPCs including ApiVersion
> > and
> > > > map
> > > > > > to
> > > > > > > > the new version to use v3 of RequestHeader.
> > > > > > > > * On the server side, when a new request version is seen, we
> > > > enforce
> > > > > > the
> > > > > > > > presence of ClientInstanceId and reject the request if it is
> > > > missing.
> > > > > > > > Essentially, treat it as a required field. We also cache the
> > > > clientId
> > > > > > from
> > > > > > > > the first request and ignore it from subsequent ones.
> > > > > > > > * We would introduce OffsetDelete v1 as the first flexible
> > version
> > > > so
> > > > > > that
> > > > > > > > it uses the v3 request header.
> > > > > > > > * We would update PushTelemetry and GetTelemetrySubscriptions
> > as
> > > > > > described
> > > > > > > > in the KIP and the ClientInstanceId would move to the request
> > > > header.
> > > > > > > >
> > > > > > > > In the future, if we want to add a new truly optional field to
> > > > > > > > RequestHeader, we can continue adding it as a tagged field
> > without
> > > > > > bumping
> > > > > > > > up the request version. To add a required field, we will add
> > it as
> > > > a
> > > > > > tagged
> > > > > > > > field but force a version bump to all requests.
> > > > > > > >
> > > > > > > > The benefit of this approach is that (1) it's compatible with
> > the
> > > > > > format of
> > > > > > > > the old request header; (2) it avoids duplicating new fields;
> > and
> > > > (3)
> > > > > > there
> > > > > > > > is no constraint on deprecating the old request header. It's
> > > > slightly
> > > > > > weird
> > > > > > > > to bump up the version when adding a tagged field. But it still
> > > > seems
> > > > > > > > better than the alternatives.
> > > > > > > >
> > > > > > > > JR34. Since we now have different feature versions gating
> > different
> > > > > > RPCs,
> > > > > > > > should we bump up GV, TV, etc., too?
> > > > > > > >
> > > > > > > > Jun
> > > > > > > >
> > > > > > > > On Thu, Jun 25, 2026 at 10:37 AM Andrew Schofield <
> > > > > > schofielaj@apache.org>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi Jun,
> > > > > > > > > Thanks for the reply.
> > > > > > > > >
> > > > > > > > > JR27.1: What if we want to add non-optional fields to the
> > request
> > > > > > header
> > > > > > > > > in the future? I think that such fields would be by
> > definition
> > > > future
> > > > > > > > > fields which would not be understood by existing brokers. For
> > > > > > serialization
> > > > > > > > > reasons, I think we would use version 2+ tagged fields and
> > the
> > > > > > requirement
> > > > > > > > > for non-optionality would be enforced by code, rather than
> > by the
> > > > > > protocol
> > > > > > > > > schema. This avoids the field duplication.
> > > > > > > > >
> > > > > > > > > JR27.2: Yes, I don't like it, but when we inevitably do
> > another
> > > > > > KIP-896 to
> > > > > > > > > remove support for ancient parts of the protocol, it's going
> > to
> > > > be
> > > > > > another
> > > > > > > > > KIP. That's all I meant.
> > > > > > > > >
> > > > > > > > > If I understand your proposal correctly compared with the
> > > > existing
> > > > > > KIP
> > > > > > > > > text, it would look like this:
> > > > > > > > > * Remove RequestHeader v3, and introduce ClientInstanceId as
> > a
> > > > tagged
> > > > > > > > > field for versions 2+.
> > > > > > > > > * Bump the request versions for all RPCs. We'd update the
> > request
> > > > > > JSON
> > > > > > > > > schemas with something like "ClientInstanceIdVersions": "X+".
> > > > This
> > > > > > would
> > > > > > > > > mean that the request would only be properly formed if it
> > had the
> > > > > > > > > ClientInstanceId present, and would also mean that ClientId
> > > > could be
> > > > > > null
> > > > > > > > > for non-initial requests on each connection.
> > > > > > > > > * We would create ApiVersions v6, simply as a matter of the
> > > > bumping
> > > > > > of
> > > > > > > > > request versions for all RPCs, but its schema would be
> > unchanged
> > > > > > from v5.
> > > > > > > > > * We would introduce OffsetDelete v1 as the first flexible
> > > > version
> > > > > > so that
> > > > > > > > > it uses the v2 request header.
> > > > > > > > > * We would update PushTelemetry and
> > GetTelemetrySubscriptions as
> > > > > > described
> > > > > > > > > in the KIP and the ClientInstanceId would move to the request
> > > > header.
> > > > > > > > >
> > > > > > > > > I think that works roughly the same as what we have today. I
> > > > don't
> > > > > > really
> > > > > > > > > like the mandatory nature of the tagged field, but then I
> > don't
> > > > > > really like
> > > > > > > > > the way that ApiVersions is pegged on a historical request
> > header
> > > > > > version.
> > > > > > > > >
> > > > > > > > > Do I have this correct? If so, I can update the KIP
> > accordingly.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Andrew
> > > > > > > > >
> > > > > > > > > On 2026/06/24 23:40:06 Jun Rao via dev wrote:
> > > > > > > > > > Hi, Andrew,
> > > > > > > > > >
> > > > > > > > > > Thanks for the reply.
> > > > > > > > > >
> > > > > > > > > > JR27.1 What if we want to add non-optional fields to the
> > > > request
> > > > > > header
> > > > > > > > > in
> > > > > > > > > > the future? The choice I see is duplicating the field in
> > the
> > > > new
> > > > > > request
> > > > > > > > > > header and the new ApiVersion request. But it's not very
> > clean.
> > > > > > > > > > JR27.2 Requiring a major version API compatibility KIP is
> > also
> > > > a
> > > > > > bit
> > > > > > > > > > awkward.
> > > > > > > > > >
> > > > > > > > > > Here is yet another proposal. We add the ClientInstanceId
> > to
> > > > the
> > > > > > request
> > > > > > > > > > header as a tagged field and also bump up all request
> > versions.
> > > > > > This
> > > > > > > > > avoids
> > > > > > > > > > the header compatibility issue in SocketServer. The
> > bumped-up
> > > > > > version
> > > > > > > > > > signals that the new field is actually required. On the
> > server
> > > > > > side, when
> > > > > > > > > > receiving the new version of a request, we verify that the
> > > > > > > > > ClientInstanceId
> > > > > > > > > > field exists. If it's not present, we reject the request.
> > This
> > > > > > will be
> > > > > > > > > the
> > > > > > > > > > convention for adding future required fields to the header.
> > > > > > Compared to
> > > > > > > > > the
> > > > > > > > > > current proposal, this avoids duplicating the field between
> > > > request
> > > > > > > > > header
> > > > > > > > > > and ApiVersionRequest, and it provides a path for
> > deprecating
> > > > the
> > > > > > older
> > > > > > > > > > version of the request header. What do you think?
> > > > > > > > > >
> > > > > > > > > > Jun
> > > > > > > > > >
> > > > > > > > > > On Wed, Jun 24, 2026 at 2:15 AM Andrew Schofield <
> > > > > > schofielaj@apache.org>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi Jun,
> > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > >
> > > > > > > > > > > JR27: Yes, I enhanced that section of the KIP.
> > > > > > > > > > > JR27.1: This KIP was unusual because we wanted to add a
> > > > concept
> > > > > > which
> > > > > > > > > > > existed in the KIP-714 RPCs to the request header,
> > > > complicating
> > > > > > the
> > > > > > > > > > > behavior of those RPCs, AND we wanted to change the
> > handling
> > > > of
> > > > > > client
> > > > > > > > > ID
> > > > > > > > > > > without breaking older brokers. If we simply wanted to
> > add a
> > > > > > brand new
> > > > > > > > > > > field to the request header, we can do it as a tagged
> > field
> > > > in
> > > > > > request
> > > > > > > > > > > header versions 2+.
> > > > > > > > > > > JR27.2: Covered this too. We'd need a major version API
> > > > > > compatibility
> > > > > > > > > KIP.
> > > > > > > > > > >
> > > > > > > > > > > JR31: Yes. KIP updated.
> > > > > > > > > > >
> > > > > > > > > > > JR32: Yes. This is a minor inconvenience I feel. KIP
> > updated.
> > > > > > > > > > >
> > > > > > > > > > > JR33: I don't see the value of a string comparison here.
> > > > > > Personally,
> > > > > > > > > I'm
> > > > > > > > > > > happy with "assume".
> > > > > > > > > > >
> > > > > > > > > > > Thanks,
> > > > > > > > > > > Andrew
> > > > > > > > > > >
> > > > > > > > > > > On 2026/06/23 22:52:15 Jun Rao via dev wrote:
> > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > >
> > > > > > > > > > > > JR27. The code that changed the request header parsing
> > was
> > > > > > > > > introduced in
> > > > > > > > > > > > 2019 (
> > > > > > > > > > >
> > > > > > > > >
> > > > > >
> > > >
> > https://urldefense.com/v3/__https://github.com/apache/kafka/pull/7372__;!!Ayb5sqE7!scbWbTEEm2o-Y3MBGi829H2cpMWPRyrF9g2CW3lmRHyRmgBU2MyoRif2mFJpnfmvQ2x7fF4LrAJXdwH86ERR$
> > > > > > > > > > > ). I agree that fixing it
> > > > > > > > > > > > now is too late. We should document the path forward
> > for
> > > > > > ApiVersion.
> > > > > > > > > > > Could
> > > > > > > > > > > > we answer at least the following questions in the
> > > > > > Compatibility,
> > > > > > > > > > > > Deprecation, and Migration Plan section?
> > > > > > > > > > > > JR27.1 What happens to ApiVersion if we change the
> > request
> > > > > > header in
> > > > > > > > > the
> > > > > > > > > > > > future?
> > > > > > > > > > > > JR27.2 What happens if we ever want to deprecate v2 of
> > the
> > > > > > request
> > > > > > > > > > > header?
> > > > > > > > > > > >
> > > > > > > > > > > > JR28. The new MV needs to be covered in the
> > Compatibility,
> > > > > > > > > Deprecation,
> > > > > > > > > > > and
> > > > > > > > > > > > Migration Plan section.
> > > > > > > > > > > >
> > > > > > > > > > > > JR31. "If a connection uses the v3 request header in
> > its
> > > > first
> > > > > > > > > request,
> > > > > > > > > > > it
> > > > > > > > > > > > must specify a non-zero client instance ID and it must
> > > > specify
> > > > > > the
> > > > > > > > > same
> > > > > > > > > > > > client instance ID for all subsequent requests."
> > > > > > > > > > > > Do we do the same if the first request is v6 of
> > ApiVersion?
> > > > > > > > > > > >
> > > > > > > > > > > > JR32. "For subsequent requests using an earlier
> > version of
> > > > the
> > > > > > > > > request
> > > > > > > > > > > > header, the client sends the client ID". This means
> > that
> > > > > > subsequent
> > > > > > > > > > > > ApiVersion V6 requests will carry the non-null clientID
> > > > > > > > > unnecessarily.
> > > > > > > > > > > >
> > > > > > > > > > > > JR33. "After this KIP, the broker will assume that the
> > > > client
> > > > > > ID
> > > > > > > > > from the
> > > > > > > > > > > > initial request applies to all subsequent requests on a
> > > > > > connection,
> > > > > > > > > and
> > > > > > > > > > > it
> > > > > > > > > > > > will ignore the client ID specified on any subsequent
> > > > > > requests."
> > > > > > > > > > > > Should the broker verify that the clientId from
> > subsequent
> > > > > > request
> > > > > > > > > match
> > > > > > > > > > > > the first cached one, if not null?
> > > > > > > > > > > >
> > > > > > > > > > > >  Jun
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Jun 23, 2026 at 6:05 AM Andrew Schofield <
> > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > Thanks for your reply.
> > > > > > > > > > > > >
> > > > > > > > > > > > > JR27: Unfortunately, I don't think this is
> > acceptable. We
> > > > > > would be
> > > > > > > > > > > saying
> > > > > > > > > > > > > that AK 4.5 clients can only connect to AK 4.5 or
> > later
> > > > > > brokers,
> > > > > > > > > and
> > > > > > > > > > > that
> > > > > > > > > > > > > we'd create patch release for AK 4.0.x to AK 4.4.x.
> > so
> > > > AK 4.5
> > > > > > > > > clients
> > > > > > > > > > > could
> > > > > > > > > > > > > connect to those too. We'd be preventing connection
> > to
> > > > AK 3.x
> > > > > > > > > brokers
> > > > > > > > > > > by AK
> > > > > > > > > > > > > 4.5 clients. I don't see how we can break
> > compatibility
> > > > in a
> > > > > > minor
> > > > > > > > > > > release.
> > > > > > > > > > > > > Here's the existing compatibility table:
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > >
> > > >
> > https://urldefense.com/v3/__https://kafka.apache.org/41/getting-started/compatibility/__;!!Ayb5sqE7!ppWU_jI9f7EY9DYwcbiOESSBG2TmPn9CHfLnVM5TaIMwWqHUbUbIiGre1GGKMr-HmelQlyP6ibUSyORCAgte$
> > > > > > > > > > > > >
> > > > > > > > > > > > > JR29: OK, makes sense to me.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > Andrew
> > > > > > > > > > > > >
> > > > > > > > > > > > > On 2026/06/22 21:50:43 Jun Rao via dev wrote:
> > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > JR27. I am not sure I like the approach of pinning
> > the
> > > > > > header to
> > > > > > > > > v2
> > > > > > > > > > > for
> > > > > > > > > > > > > > ApiVersionsRequest. This means that in the future,
> > each
> > > > > > change
> > > > > > > > > to the
> > > > > > > > > > > > > > request header must be duplicated in the request
> > > > itself.
> > > > > > Here is
> > > > > > > > > an
> > > > > > > > > > > > > > alternative. Note that to detect an unsupported
> > > > > > > > > ApiVersionRequest, we
> > > > > > > > > > > > > don't
> > > > > > > > > > > > > > need to parse the full v2 request header. Parsing
> > the
> > > > > > first two
> > > > > > > > > > > fields
> > > > > > > > > > > > > > ApiKey and ApiVersion is enough. So, we could
> > patch all
> > > > > > the 4.x
> > > > > > > > > > > releases
> > > > > > > > > > > > > > with a change that short-circuits parsing the full
> > > > request
> > > > > > header
> > > > > > > > > > > based
> > > > > > > > > > > > > on
> > > > > > > > > > > > > > the first two fields. Then, we recommend upgrading
> > > > from the
> > > > > > > > > latest
> > > > > > > > > > > 4.x
> > > > > > > > > > > > > > releases to future releases. This way, we can
> > still let
> > > > > > > > > > > > > ApiVersionsRequest
> > > > > > > > > > > > > > depend on the request header for current and future
> > > > > > changes.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > JR29. The simplest thing is to upgrade the KRaft
> > RPCs
> > > > too
> > > > > > to be
> > > > > > > > > > > > > consistent.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Sat, Jun 20, 2026 at 3:38 AM Andrew Schofield <
> > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > Thanks for these insightful comments. I did
> > > > prototype the
> > > > > > > > > earlier
> > > > > > > > > > > v2
> > > > > > > > > > > > > > > request header with tagged fields variant. I
> > have now
> > > > > > > > > prototyped
> > > > > > > > > > > the v3
> > > > > > > > > > > > > > > request header variant.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR27: You were of course entirely correct that a
> > new
> > > > > > version of
> > > > > > > > > > > > > > > ApiVersions request cannot use a request header
> > > > which is
> > > > > > not
> > > > > > > > > > > > > > > binary-compatible with what has gone before. As a
> > > > > > result, I
> > > > > > > > > have
> > > > > > > > > > > > > introduced
> > > > > > > > > > > > > > > a new version of ApiVersions request which
> > includes
> > > > > > > > > > > ClientInstanceId
> > > > > > > > > > > > > in the
> > > > > > > > > > > > > > > request body but continues to use the v2 request
> > > > header.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR28: Yes, we need a new metadata version, which
> > is
> > > > > > > > > provisionally
> > > > > > > > > > > > > > > IBP_4_5_IV0. I'll update the KIP with the final
> > value
> > > > > > when it
> > > > > > > > > is
> > > > > > > > > > > > > assigned.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR29: I don't have any strong feelings on this. I
> > > > > > suppose for
> > > > > > > > > each
> > > > > > > > > > > > > inter
> > > > > > > > > > > > > > > broker RPC version that is bumped, we need to
> > > > introduce
> > > > > > an MV
> > > > > > > > > > > check. We
> > > > > > > > > > > > > > > cannot avoid this for RPCs which are also used by
> > > > > > clients such
> > > > > > > > > as
> > > > > > > > > > > > > Fetch.
> > > > > > > > > > > > > > > For purely inter-broker RPCs, we could just
> > exempt
> > > > them
> > > > > > from
> > > > > > > > > the
> > > > > > > > > > > > > version
> > > > > > > > > > > > > > > bump. What do you recommend here?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR30: Done. INVALID_REQUEST. I did consider
> > > > permitting
> > > > > > zero
> > > > > > > > > client
> > > > > > > > > > > > > > > instance ID for inter-broker connections, but I
> > > > decided
> > > > > > that I
> > > > > > > > > > > > > preferred
> > > > > > > > > > > > > > > not creating another rule.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On 2026/06/17 22:45:07 Andrew Schofield wrote:
> > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > JR27: I am familiar with KIP-511 and the
> > oddness of
> > > > > > > > > ApiVersions.
> > > > > > > > > > > You
> > > > > > > > > > > > > > > make an excellent point. I suspect that
> > > > > > ApiVersionsRequest will
> > > > > > > > > > > have
> > > > > > > > > > > > > to be
> > > > > > > > > > > > > > > limited to the v2 request header, just as it is
> > > > > > restricted to
> > > > > > > > > the
> > > > > > > > > > > v0
> > > > > > > > > > > > > > > response header.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I'll do some experimentation.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On 2026/06/17 17:35:17 Jun Rao via dev wrote:
> > > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Thanks for the reply. A few more comments.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > JR27. It seems that we have a compatibility
> > issue
> > > > > > with
> > > > > > > > > > > > > > > ApiVersionRequest v6
> > > > > > > > > > > > > > > > > depending on RequestHeader v3. This happens
> > when
> > > > a
> > > > > > new
> > > > > > > > > client
> > > > > > > > > > > > > issues
> > > > > > > > > > > > > > > > > ApiVersionRequest v6 to an old broker (one
> > that
> > > > only
> > > > > > > > > supports
> > > > > > > > > > > > > > > > > ApiVersionRequest v5). The SocketServer in
> > the
> > > > > > broker will
> > > > > > > > > > > first
> > > > > > > > > > > > > try to
> > > > > > > > > > > > > > > > > read the request header. It tries to find the
> > > > header
> > > > > > > > > version
> > > > > > > > > > > from
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > request version. Since the broker doesn't
> > know
> > > > > > > > > > > ApiVersionRequest
> > > > > > > > > > > > > v6, it
> > > > > > > > > > > > > > > > > uses v2 to parse the request header.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > The v2's wire format for the request header
> > is:
> > > > > > ApiKey |
> > > > > > > > > > > > > ApiVersion |
> > > > > > > > > > > > > > > > > CorrelationId | ClientId |
> > tagged-fields-varint
> > > > > > > > > > > > > > > > > The v3's wire format for the request header
> > is:
> > > > > > ApiKey |
> > > > > > > > > > > > > ApiVersion |
> > > > > > > > > > > > > > > > > CorrelationId | ClientId |
> > ClientInstanceId(16
> > > > > > bytes) |
> > > > > > > > > > > > > tagged-fields
> > > > > > > > > > > > > > > varint
> > > > > > > > > > > > > > > > > The first 4 fields are identical, allowing
> > the
> > > > > > broker to
> > > > > > > > > parse
> > > > > > > > > > > > > them.
> > > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > > broker then tries to read the
> > > > tagged-fields-varint
> > > > > > using
> > > > > > > > > the
> > > > > > > > > > > > > serialized
> > > > > > > > > > > > > > > > > bytes intended for ClientInstanceId. This
> > could
> > > > lead
> > > > > > to a
> > > > > > > > > > > parsing
> > > > > > > > > > > > > > > error and
> > > > > > > > > > > > > > > > > raise an invalid request error. The broker
> > will
> > > > > > close the
> > > > > > > > > > > > > connection
> > > > > > > > > > > > > > > > > instead of sending a v0 response for
> > > > > > ApiVersionRequest.
> > > > > > > > > Then
> > > > > > > > > > > the
> > > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > will never be able to detect supported API
> > > > versions
> > > > > > on the
> > > > > > > > > old
> > > > > > > > > > > > > broker.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > The same problem didn't exist when
> > > > ApiVersionRequest
> > > > > > > > > changed
> > > > > > > > > > > from
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > v1
> > > > > > > > > > > > > > > > > request header to v2 because the wire format
> > for
> > > > v1
> > > > > > is a
> > > > > > > > > > > prefix of
> > > > > > > > > > > > > v2.
> > > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > > problem exists for this KIP because the wire
> > > > format
> > > > > > of v2
> > > > > > > > > is no
> > > > > > > > > > > > > longer
> > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > prefix of v3.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > JR28. Since we are bumping up the version of
> > > > inter
> > > > > > broker
> > > > > > > > > > > > > requests, we
> > > > > > > > > > > > > > > need
> > > > > > > > > > > > > > > > > to gate them by introducing a new MV.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > JR29. Could you specify whether the version
> > for
> > > > > > KRaft PRCs
> > > > > > > > > > > will be
> > > > > > > > > > > > > > > bumped
> > > > > > > > > > > > > > > > > too?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > JR30. "If a connection uses the v3 request
> > > > header in
> > > > > > its
> > > > > > > > > first
> > > > > > > > > > > > > > > request, it
> > > > > > > > > > > > > > > > > must specify a non-zero client instance ID"
> > > > > > > > > > > > > > > > > Could we define the broker's behavior when a
> > v3
> > > > > > request
> > > > > > > > > header
> > > > > > > > > > > > > > > contains a 0
> > > > > > > > > > > > > > > > > client instance ID?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Tue, Jun 16, 2026 at 1:25 AM Andrew
> > Schofield
> > > > <
> > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > JR26: Yes, I was considering open-ended
> > version
> > > > > > ranges.
> > > > > > > > > I've
> > > > > > > > > > > > > updated
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > KIP.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Now that we have a new request header
> > version,
> > > > I
> > > > > > think
> > > > > > > > > it's
> > > > > > > > > > > safe
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > reintroduce the client ID optimisation.
> > I've
> > > > added
> > > > > > that
> > > > > > > > > into
> > > > > > > > > > > the
> > > > > > > > > > > > > KIP
> > > > > > > > > > > > > > > also.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Let me know what you think.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On 2026/06/15 17:46:00 Jun Rao via dev
> > wrote:
> > > > > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Thanks for the reply. Just a minor
> > comment.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > JR26. "The keys of the map are either
> > single
> > > > > > versions
> > > > > > > > > like
> > > > > > > > > > > "0"
> > > > > > > > > > > > > or
> > > > > > > > > > > > > > > closed
> > > > > > > > > > > > > > > > > > > version ranges like "1-2"."
> > > > > > > > > > > > > > > > > > > It will be useful to support open-ended
> > > > > > versions. That
> > > > > > > > > way,
> > > > > > > > > > > > > "3":
> > > > > > > > > > > > > > > "3"
> > > > > > > > > > > > > > > > > > could
> > > > > > > > > > > > > > > > > > > be "3+": "3". This part won't need to
> > change
> > > > in
> > > > > > the
> > > > > > > > > future
> > > > > > > > > > > > > when we
> > > > > > > > > > > > > > > bump
> > > > > > > > > > > > > > > > > > up
> > > > > > > > > > > > > > > > > > > the request version without changing the
> > > > header.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Fri, Jun 12, 2026 at 2:12 PM Andrew
> > > > Schofield
> > > > > > <
> > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > JR25: I agree. I've changed to a
> > > > > > headerVersions map
> > > > > > > > > in
> > > > > > > > > > > both
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > request
> > > > > > > > > > > > > > > > > > > > and response schemas.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Let me know what you think.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On 2026/06/12 03:39:39 Jun Rao via dev
> > > > wrote:
> > > > > > > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Thanks for the updated KIP.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > JR25. I have some concerns about
> > adding
> > > > the
> > > > > > > > > > > > > > > clientInstanceIdVersions
> > > > > > > > > > > > > > > > > > > > field
> > > > > > > > > > > > > > > > > > > > > to the schema. First of all, it only
> > > > applies
> > > > > > to
> > > > > > > > > > > requests,
> > > > > > > > > > > > > but
> > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > > > > > responses. So, it's a bit weird to
> > add
> > > > it to
> > > > > > the
> > > > > > > > > > > general
> > > > > > > > > > > > > > > schema.
> > > > > > > > > > > > > > > > > > > > Secondly,
> > > > > > > > > > > > > > > > > > > > > it's very specific to the new field
> > > > added to
> > > > > > the
> > > > > > > > > > > request
> > > > > > > > > > > > > > > header. If
> > > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > > change the request header again in
> > the
> > > > > > future, we
> > > > > > > > > need
> > > > > > > > > > > > > another
> > > > > > > > > > > > > > > way
> > > > > > > > > > > > > > > > > > to map
> > > > > > > > > > > > > > > > > > > > > request versions to the new header
> > > > version.
> > > > > > > > > Ideally, we
> > > > > > > > > > > > > should
> > > > > > > > > > > > > > > have a
> > > > > > > > > > > > > > > > > > > > > generic way to map request versions
> > to
> > > > all
> > > > > > future
> > > > > > > > > > > header
> > > > > > > > > > > > > > > versions.
> > > > > > > > > > > > > > > > > > One
> > > > > > > > > > > > > > > > > > > > > possibility is to introduce a
> > > > headerVersion
> > > > > > field
> > > > > > > > > in
> > > > > > > > > > > the
> > > > > > > > > > > > > > > schema.
> > > > > > > > > > > > > > > > > > Then,
> > > > > > > > > > > > > > > > > > > > each
> > > > > > > > > > > > > > > > > > > > > request/response can use this field
> > to
> > > > map
> > > > > > its
> > > > > > > > > > > versions to
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > header
> > > > > > > > > > > > > > > > > > > > > versions.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Tue, Jun 9, 2026 at 4:55 AM Andrew
> > > > > > Schofield <
> > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Hi Matthias,
> > > > > > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I have change the version property
> > for
> > > > > > > > > introducing
> > > > > > > > > > > client
> > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > ID
> > > > > > > > > > > > > > > > > > > > into
> > > > > > > > > > > > > > > > > > > > > > the request headers to be
> > > > > > > > > `clientInstanceIdVersions`
> > > > > > > > > > > > > which
> > > > > > > > > > > > > > > is now
> > > > > > > > > > > > > > > > > > an
> > > > > > > > > > > > > > > > > > > > > > open-ended range, such as "3+",
> > more
> > > > > > closely
> > > > > > > > > matching
> > > > > > > > > > > > > what
> > > > > > > > > > > > > > > we have
> > > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > > flexible versions.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I also added a change to the
> > > > > > > > > > > > > > > RebalanceConsumer.clientInstanceId
> > > > > > > > > > > > > > > > > > method
> > > > > > > > > > > > > > > > > > > > > > introduced in KIP-1306.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On 2026/06/03 18:31:06 "Matthias J.
> > > > Sax"
> > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > Thanks Andrew.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >  From a KIP-714 perspective,
> > this is
> > > > a
> > > > > > great
> > > > > > > > > > > change,
> > > > > > > > > > > > > as it
> > > > > > > > > > > > > > > make
> > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > new
> > > > > > > > > > > > > > > > > > > > > > > RPCs and client/broker
> > cross-version
> > > > > > > > > compatibility
> > > > > > > > > > > > > clean.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > One question about your
> > > > `DeleteGroups`
> > > > > > RPC
> > > > > > > > > example.
> > > > > > > > > > > > > Should
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > new
> > > > > > > > > > > > > > > > > > > > > > > version of the RPC say
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > "clientInstanceIdVersion":
> > "3+",
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > ie, 3+ instead of 3? Similar for
> > > > other
> > > > > > request,
> > > > > > > > > > > which
> > > > > > > > > > > > > > > don't use
> > > > > > > > > > > > > > > > > > `+`
> > > > > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > > > `clientInstanceIdVersion` field.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > -Matthias
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > On 6/2/26 7:42 AM, Andrew
> > Schofield
> > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > > Following on from the
> > discussion
> > > > in the
> > > > > > > > > > > community,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > difficulty
> > > > > > > > > > > > > > > > > > > > > > of trying to accommodate the client
> > > > > > instance ID
> > > > > > > > > in a
> > > > > > > > > > > > > tagged
> > > > > > > > > > > > > > > field
> > > > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > > > > > acceptable complexity, I have made
> > a
> > > > > > significant
> > > > > > > > > > > change
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > the KIP.
> > > > > > > > > > > > > > > > > > > > Now, it
> > > > > > > > > > > > > > > > > > > > > > introduces v3 of the request header
> > > > > > containing
> > > > > > > > > the
> > > > > > > > > > > client
> > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > ID
> > > > > > > > > > > > > > > > > > > > as a
> > > > > > > > > > > > > > > > > > > > > > proper field.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > >
> > > >
> > https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/KAFKA/KIP-1313*3A*Client*instance*ID*in*all*request*headers__;JSsrKysrKys!!Ayb5sqE7!pUZS25PuTKdhiqvTGcwDKbclqpG8dFOzw2Ax9WxVM6Sb09PVQ0gl1i0gjlr2_Krr66agbuVC2qLGgUcg7vrW$
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Please review and let me know
> > what
> > > > you
> > > > > > think.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > On 2026/05/28 21:51:01
> > "Matthias J.
> > > > > > Sax"
> > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > >> Thanks Andrew. I agree to the
> > > > issue
> > > > > > that
> > > > > > > > > tagged
> > > > > > > > > > > > > fields
> > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > > optional.
> > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > >> Nevertheless, I find the
> > proposed
> > > > > > > > > compatibility
> > > > > > > > > > > > > > > protocol too
> > > > > > > > > > > > > > > > > > > > complex
> > > > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > > > >> unnecessary, and would still
> > > > prefer a
> > > > > > > > > version
> > > > > > > > > > > bump
> > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > `GetTelemetrySubscriptionsRequest/Reponse`
> > > > > > > > > to
> > > > > > > > > > > clean
> > > > > > > > > > > > > it
> > > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > > > > up. --
> > > > > > > > > > > > > > > > > > > > For
> > > > > > > > > > > > > > > > > > > > > > > >> `PushTelemetryRequest` the
> > > > argument
> > > > > > from
> > > > > > > > > above
> > > > > > > > > > > > > applies,
> > > > > > > > > > > > > > > so
> > > > > > > > > > > > > > > > > > > > leaving it
> > > > > > > > > > > > > > > > > > > > > > > >> untouched is ok.
> > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > >> I don't see why
> > > > > > > > > > > `GetTelemetrySubscriptionsRequest`
> > > > > > > > > > > > > > > would need
> > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > encode
> > > > > > > > > > > > > > > > > > > > > > > >> the `clientInstandId` in it's
> > > > request
> > > > > > body.
> > > > > > > > > > > Given
> > > > > > > > > > > > > that
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > >> `clientInstanceId` is a random
> > > > UUID,
> > > > > > the
> > > > > > > > > > > returned
> > > > > > > > > > > > > > > subscription
> > > > > > > > > > > > > > > > > > > > cannot
> > > > > > > > > > > > > > > > > > > > > > > >> really depend on it. So why
> > would
> > > > we
> > > > > > need to
> > > > > > > > > > > send
> > > > > > > > > > > > > it to
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > broker?
> > > > > > > > > > > > > > > > > > > > > > > >> Right now, it's set to ZERO
> > only
> > > > for
> > > > > > the
> > > > > > > > > > > purpose to
> > > > > > > > > > > > > get
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > broker to
> > > > > > > > > > > > > > > > > > > > > > > >> assign a new UUID. But it has
> > > > nothing
> > > > > > to do
> > > > > > > > > > > with the
> > > > > > > > > > > > > > > actual
> > > > > > > > > > > > > > > > > > "what
> > > > > > > > > > > > > > > > > > > > > > > >> metrics should I send"
> > question.
> > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > >> To be fair, KIP-714 lists
> > > > > > > > > `client_instance_id`
> > > > > > > > > > > as a
> > > > > > > > > > > > > > > field that
> > > > > > > > > > > > > > > > > > > > can be
> > > > > > > > > > > > > > > > > > > > > > > >> used to define a subscription.
> > > > But it
> > > > > > seems
> > > > > > > > > > > rather
> > > > > > > > > > > > > > > useless in
> > > > > > > > > > > > > > > > > > > > practice
> > > > > > > > > > > > > > > > > > > > > > > >> to me? I a user defines a
> > > > > > subscription, they
> > > > > > > > > > > cannot
> > > > > > > > > > > > > > > know the
> > > > > > > > > > > > > > > > > > UUID.
> > > > > > > > > > > > > > > > > > > > > > Thus,
> > > > > > > > > > > > > > > > > > > > > > > >> I think we should actually
> > drop
> > > > > > supporting
> > > > > > > > > > > > > > > > > > `client_instance_id`
> > > > > > > > > > > > > > > > > > > > as a
> > > > > > > > > > > > > > > > > > > > > > > >> "subscription matching
> > > > parameter"? Of
> > > > > > > > > course,
> > > > > > > > > > > there
> > > > > > > > > > > > > is a
> > > > > > > > > > > > > > > > > > backward
> > > > > > > > > > > > > > > > > > > > > > > >> compatibility question, but I
> > > > think
> > > > > > we can
> > > > > > > > > > > address
> > > > > > > > > > > > > > > this: if
> > > > > > > > > > > > > > > > > > > > brokers
> > > > > > > > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > > > > > >> upgraded and they have an
> > existing
> > > > > > > > > > > > > `client_instance_id`
> > > > > > > > > > > > > > > based
> > > > > > > > > > > > > > > > > > > > > > > >> subscription defined, they
> > could
> > > > > > advertise
> > > > > > > > > to
> > > > > > > > > > > only
> > > > > > > > > > > > > > > support
> > > > > > > > > > > > > > > > > > v0, and
> > > > > > > > > > > > > > > > > > > > > > they
> > > > > > > > > > > > > > > > > > > > > > > >> should log a warning that this
> > > > > > feature is
> > > > > > > > > > > > > deprecated.
> > > > > > > > > > > > > > > New
> > > > > > > > > > > > > > > > > > brokers
> > > > > > > > > > > > > > > > > > > > > > would
> > > > > > > > > > > > > > > > > > > > > > > >> also not allow to use
> > > > > > `client_instance_id`
> > > > > > > > > any
> > > > > > > > > > > > > longer to
> > > > > > > > > > > > > > > > > > define a
> > > > > > > > > > > > > > > > > > > > > > > >> subscription.
> > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > >> Similarly, for
> > > > > > > > > > > `GetTelemetrySubscriptionsResponse`,
> > > > > > > > > > > > > we
> > > > > > > > > > > > > > > only
> > > > > > > > > > > > > > > > > > need
> > > > > > > > > > > > > > > > > > > > > > > >> `clientInstanceId` if the
> > broker
> > > > > > computes
> > > > > > > > > the
> > > > > > > > > > > UUID.
> > > > > > > > > > > > > But
> > > > > > > > > > > > > > > if we
> > > > > > > > > > > > > > > > > > let
> > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > > >> client compute it, this field
> > is
> > > > not
> > > > > > needed
> > > > > > > > > any
> > > > > > > > > > > > > longer.
> > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > >> -Matthias
> > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > >> On 5/28/26 1:21 AM, Andrew
> > > > Schofield
> > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > >>> Hi Jun,
> > > > > > > > > > > > > > > > > > > > > > > >>> Thanks for your response.
> > > > > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > > > > >>> JR24: I'll update the KIP
> > > > shortly.
> > > > > > Here's a
> > > > > > > > > > > > > summary.
> > > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > > > various
> > > > > > > > > > > > > > > > > > > > > > modern group protocol heartbeat
> > > > requests
> > > > > > encode
> > > > > > > > > the
> > > > > > > > > > > > > member
> > > > > > > > > > > > > > > ID as a
> > > > > > > > > > > > > > > > > > > > string
> > > > > > > > > > > > > > > > > > > > > > for historical reasons, even though
> > > > it's in
> > > > > > > > > practice
> > > > > > > > > > > a
> > > > > > > > > > > > > UUID.
> > > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > > > Apache
> > > > > > > > > > > > > > > > > > > > > > Kafka Java client happens to use
> > > > > > > > > > > > > > > org.apache.kafka.common.Uuid to
> > > > > > > > > > > > > > > > > > > > create the
> > > > > > > > > > > > > > > > > > > > > > member ID and convert it into a
> > string.
> > > > > > This
> > > > > > > > > means
> > > > > > > > > > > that
> > > > > > > > > > > > > when
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > clientInstanceId is converted into
> > a
> > > > > > string, its
> > > > > > > > > > > encoding
> > > > > > > > > > > > > > > matches
> > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > member ID and it all lines up.
> > However,
> > > > > > there are
> > > > > > > > > > > other
> > > > > > > > > > > > > ways
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > encode
> > > > > > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > > > > > UUID into a string and I know for a
> > > > fact
> > > > > > that the
> > > > > > > > > > > > > librdkafka
> > > > > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > > > > does it
> > > > > > > > > > > > > > > > > > > > > > differently.
> > > > > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > > > > >>> Thanks,
> > > > > > > > > > > > > > > > > > > > > > > >>> Andrew
> > > > > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > > > > >>> On 2026/05/27 17:11:25 Jun
> > Rao
> > > > via
> > > > > > dev
> > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > >>>> Hi, Andrew,
> > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > >>>> Thanks for the reply. One
> > more
> > > > > > comment.
> > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > >>>> JR24. "The alignment of
> > other
> > > > > > identifiers
> > > > > > > > > is
> > > > > > > > > > > by
> > > > > > > > > > > > > > > convention
> > > > > > > > > > > > > > > > > > (and
> > > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > Java
> > > > > > > > > > > > > > > > > > > > > > > >>>> client will follow the
> > > > convention)
> > > > > > rather
> > > > > > > > > than
> > > > > > > > > > > > > > > mandate."
> > > > > > > > > > > > > > > > > > Could
> > > > > > > > > > > > > > > > > > > > you
> > > > > > > > > > > > > > > > > > > > > > describe
> > > > > > > > > > > > > > > > > > > > > > > >>>> the convention to convert a
> > > > > > > > > clientInstanceId
> > > > > > > > > > > > > (UUID)
> > > > > > > > > > > > > > > to a
> > > > > > > > > > > > > > > > > > > > memberId
> > > > > > > > > > > > > > > > > > > > > > (String)?
> > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > >>>> Jun
> > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > >>>> On Tue, May 19, 2026 at
> > 2:36 AM
> > > > > > Andrew
> > > > > > > > > > > Schofield <
> > > > > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > >>>>> 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 <
> > > > > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > >>>>>> 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 <
> > > > > > > > > > > > > > > > > > > > > > > >>>>>>> schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> 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 <
> > > > > > > > > > > > > > > > > > > > > > > >>>>>>> schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> 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
> > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> 

Re: [DISCUSS] KIP-1313: Client instance ID in all request headers

[Jun Rao via dev <de...@kafka.apache.org>]

Hi, Andrew,

Thanks for the reply.

JR37. UUID is 16 bytes. If it's omitted in subsequent requests, we save 16
bytes, right?

Jun



On Tue, Aug 4, 2026 at 5:47 AM Andrew Schofield <sc...@apache.org>
wrote:

> Hi Jun,
> Thanks for your reply.
>
> JR37: Unlike with clientId where space is saved by not transmitting it on
> every request, there's nothing to be gained by omitting clientInstanceId on
> later requests. I prefer to leave it as is.
>
> JR38: OK, I've updated those paragraphs in the KIP to exclude the reserved
> UUIDs.
>
> Thanks,
> Andrew
>
> On 2026/08/03 20:23:39 Jun Rao via dev wrote:
> > Hi, Andrew,
> >
> > Thanks for the reply.
> >
> > JR37. Will it be better to require ClientInstanceId only on the first
> > request, to be consistent with clientId?
> >
> > JR38. "must specify a non-zero client instance ID". one_uuid is also a
> > reserved one in the Uuid class. Should we exclude that one too?
> >
> > Jun
> >
> > On Fri, Jul 31, 2026 at 9:10 AM Andrew Schofield <sc...@apache.org>
> > wrote:
> >
> > > Hi Jun,
> > > Thanks for the reply and sorry for the delay. Lots of 4.4 stuff got in
> the
> > > way.
> > >
> > > JR34: EligibleLeaderReplicasVersion and KRaftVersion also use
> ApiVersion
> > > to negotiate the RPC versions. I do not believe we need to bump up
> other
> > > feature versions as a result of the RPC version bumps in this KIP.
> > >
> > > JR35: Yes, good catch. In order to handle client ID-based quotas for
> > > forwarded requests, it will be necessary to populate the client ID in
> the
> > > forwarded request header. KIP updated.
> > >
> > > JR36: I hadn't considered MV to be a feature version, but I understand.
> > > KIP updated.
> > >
> > > Thanks,
> > > Andrew
> > >
> > > On 2026/06/29 16:23:09 Jun Rao via dev wrote:
> > > > Hi, Andrew,
> > > >
> > > > Thanks for the reply.
> > > >
> > > > JR34. Transaction coordinator uses ApiVersion to negotiate the PRC
> > > > versions. Therefore, if there is no functional change, there is no
> need
> > > to
> > > > bump the TV version. I am not sure about
> EligibleLeaderReplicasVersion
> > > > and KRaftVersion.
> > > > It would be useful to have the experts chime in.
> > > >
> > > > JR35. Envelope/forwarding interaction: When a broker forwards a
> client
> > > > request to the controller via EnvelopeUtils
> > > (parseForwardedRequestHeader),
> > > > the inner header may have its clientId optimized to null. Some quota
> > > > enforcement (e.g. controller mutation) may depend on the non-null
> > > clientId.
> > > > The per-connection caching occurs on the original client↔broker
> > > connection, not
> > > > the broker↔controller one. Should the forwarded request preserve the
> > > > non-null resolved (cached) client.id?
> > > >
> > > > JR36. "This KIP does not need to introduce any feature version
> bumps."
> > > This
> > > > is not very accurate since MV is a feature version and is bumped.
> > > >
> > > > Jun
> > > >
> > > >
> > > > On Fri, Jun 26, 2026 at 12:42 AM Andrew Schofield <
> schofielaj@apache.org
> > > >
> > > > wrote:
> > > >
> > > > > Hi Jun,
> > > > > I've updated the KIP.
> > > > >
> > > > > JS34: I don't believe that we need to introduce any new feature
> > > versions
> > > > > for this KIP. For example, we do not need a new ShareVersion since
> that
> > > > > enabled share groups (SV_1) and controls the versioning of the
> records
> > > on
> > > > > the internal topics (SV_2). I think the same applies for the
> others. I
> > > > > understand GroupVersion and StreamsVersion, and I think they
> follow the
> > > > > same reasoning as ShareVersion. I don't know TransactionVersion or
> > > > > EligibleLeaderReplicasVersion, so let me know whether those are
> > > different
> > > > > in this regard.
> > > > >
> > > > > Thanks,
> > > > > Andrew
> > > > >
> > > > > On 2026/06/25 21:32:27 Andrew Schofield wrote:
> > > > > > Hi Jun,
> > > > > > Thanks for the reply.
> > > > > >
> > > > > > JR27: Yes, makes sense. So request header v3 is binary-compatible
> > > with
> > > > > request header v2.
> > > > > >
> > > > > > JS34: Yes, I think so.
> > > > > >
> > > > > > I'll update the KIP tomorrow morning.
> > > > > >
> > > > > > Thanks,
> > > > > > Andrew
> > > > > >
> > > > > > On 2026/06/25 20:23:57 Jun Rao via dev wrote:
> > > > > > > Hi, Andrew,
> > > > > > >
> > > > > > > Thanks for the reply.
> > > > > > >
> > > > > > > JR27. I was thinking of the following, which is slightly
> different
> > > from
> > > > > > > what you described.
> > > > > > > * Bump RequestHeader to v3, and introduce ClientInstanceId as a
> > > tagged
> > > > > > > field for versions 3+ and change the semantic of the existing
> field
> > > > > > > clientId (only need to be populated by the first request).
> > > > > > > * Bump the request versions for all RPCs including ApiVersion
> and
> > > map
> > > > > to
> > > > > > > the new version to use v3 of RequestHeader.
> > > > > > > * On the server side, when a new request version is seen, we
> > > enforce
> > > > > the
> > > > > > > presence of ClientInstanceId and reject the request if it is
> > > missing.
> > > > > > > Essentially, treat it as a required field. We also cache the
> > > clientId
> > > > > from
> > > > > > > the first request and ignore it from subsequent ones.
> > > > > > > * We would introduce OffsetDelete v1 as the first flexible
> version
> > > so
> > > > > that
> > > > > > > it uses the v3 request header.
> > > > > > > * We would update PushTelemetry and GetTelemetrySubscriptions
> as
> > > > > described
> > > > > > > in the KIP and the ClientInstanceId would move to the request
> > > header.
> > > > > > >
> > > > > > > In the future, if we want to add a new truly optional field to
> > > > > > > RequestHeader, we can continue adding it as a tagged field
> without
> > > > > bumping
> > > > > > > up the request version. To add a required field, we will add
> it as
> > > a
> > > > > tagged
> > > > > > > field but force a version bump to all requests.
> > > > > > >
> > > > > > > The benefit of this approach is that (1) it's compatible with
> the
> > > > > format of
> > > > > > > the old request header; (2) it avoids duplicating new fields;
> and
> > > (3)
> > > > > there
> > > > > > > is no constraint on deprecating the old request header. It's
> > > slightly
> > > > > weird
> > > > > > > to bump up the version when adding a tagged field. But it still
> > > seems
> > > > > > > better than the alternatives.
> > > > > > >
> > > > > > > JR34. Since we now have different feature versions gating
> different
> > > > > RPCs,
> > > > > > > should we bump up GV, TV, etc., too?
> > > > > > >
> > > > > > > Jun
> > > > > > >
> > > > > > > On Thu, Jun 25, 2026 at 10:37 AM Andrew Schofield <
> > > > > schofielaj@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi Jun,
> > > > > > > > Thanks for the reply.
> > > > > > > >
> > > > > > > > JR27.1: What if we want to add non-optional fields to the
> request
> > > > > header
> > > > > > > > in the future? I think that such fields would be by
> definition
> > > future
> > > > > > > > fields which would not be understood by existing brokers. For
> > > > > serialization
> > > > > > > > reasons, I think we would use version 2+ tagged fields and
> the
> > > > > requirement
> > > > > > > > for non-optionality would be enforced by code, rather than
> by the
> > > > > protocol
> > > > > > > > schema. This avoids the field duplication.
> > > > > > > >
> > > > > > > > JR27.2: Yes, I don't like it, but when we inevitably do
> another
> > > > > KIP-896 to
> > > > > > > > remove support for ancient parts of the protocol, it's going
> to
> > > be
> > > > > another
> > > > > > > > KIP. That's all I meant.
> > > > > > > >
> > > > > > > > If I understand your proposal correctly compared with the
> > > existing
> > > > > KIP
> > > > > > > > text, it would look like this:
> > > > > > > > * Remove RequestHeader v3, and introduce ClientInstanceId as
> a
> > > tagged
> > > > > > > > field for versions 2+.
> > > > > > > > * Bump the request versions for all RPCs. We'd update the
> request
> > > > > JSON
> > > > > > > > schemas with something like "ClientInstanceIdVersions": "X+".
> > > This
> > > > > would
> > > > > > > > mean that the request would only be properly formed if it
> had the
> > > > > > > > ClientInstanceId present, and would also mean that ClientId
> > > could be
> > > > > null
> > > > > > > > for non-initial requests on each connection.
> > > > > > > > * We would create ApiVersions v6, simply as a matter of the
> > > bumping
> > > > > of
> > > > > > > > request versions for all RPCs, but its schema would be
> unchanged
> > > > > from v5.
> > > > > > > > * We would introduce OffsetDelete v1 as the first flexible
> > > version
> > > > > so that
> > > > > > > > it uses the v2 request header.
> > > > > > > > * We would update PushTelemetry and
> GetTelemetrySubscriptions as
> > > > > described
> > > > > > > > in the KIP and the ClientInstanceId would move to the request
> > > header.
> > > > > > > >
> > > > > > > > I think that works roughly the same as what we have today. I
> > > don't
> > > > > really
> > > > > > > > like the mandatory nature of the tagged field, but then I
> don't
> > > > > really like
> > > > > > > > the way that ApiVersions is pegged on a historical request
> header
> > > > > version.
> > > > > > > >
> > > > > > > > Do I have this correct? If so, I can update the KIP
> accordingly.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Andrew
> > > > > > > >
> > > > > > > > On 2026/06/24 23:40:06 Jun Rao via dev wrote:
> > > > > > > > > Hi, Andrew,
> > > > > > > > >
> > > > > > > > > Thanks for the reply.
> > > > > > > > >
> > > > > > > > > JR27.1 What if we want to add non-optional fields to the
> > > request
> > > > > header
> > > > > > > > in
> > > > > > > > > the future? The choice I see is duplicating the field in
> the
> > > new
> > > > > request
> > > > > > > > > header and the new ApiVersion request. But it's not very
> clean.
> > > > > > > > > JR27.2 Requiring a major version API compatibility KIP is
> also
> > > a
> > > > > bit
> > > > > > > > > awkward.
> > > > > > > > >
> > > > > > > > > Here is yet another proposal. We add the ClientInstanceId
> to
> > > the
> > > > > request
> > > > > > > > > header as a tagged field and also bump up all request
> versions.
> > > > > This
> > > > > > > > avoids
> > > > > > > > > the header compatibility issue in SocketServer. The
> bumped-up
> > > > > version
> > > > > > > > > signals that the new field is actually required. On the
> server
> > > > > side, when
> > > > > > > > > receiving the new version of a request, we verify that the
> > > > > > > > ClientInstanceId
> > > > > > > > > field exists. If it's not present, we reject the request.
> This
> > > > > will be
> > > > > > > > the
> > > > > > > > > convention for adding future required fields to the header.
> > > > > Compared to
> > > > > > > > the
> > > > > > > > > current proposal, this avoids duplicating the field between
> > > request
> > > > > > > > header
> > > > > > > > > and ApiVersionRequest, and it provides a path for
> deprecating
> > > the
> > > > > older
> > > > > > > > > version of the request header. What do you think?
> > > > > > > > >
> > > > > > > > > Jun
> > > > > > > > >
> > > > > > > > > On Wed, Jun 24, 2026 at 2:15 AM Andrew Schofield <
> > > > > schofielaj@apache.org>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi Jun,
> > > > > > > > > > Thanks for the reply.
> > > > > > > > > >
> > > > > > > > > > JR27: Yes, I enhanced that section of the KIP.
> > > > > > > > > > JR27.1: This KIP was unusual because we wanted to add a
> > > concept
> > > > > which
> > > > > > > > > > existed in the KIP-714 RPCs to the request header,
> > > complicating
> > > > > the
> > > > > > > > > > behavior of those RPCs, AND we wanted to change the
> handling
> > > of
> > > > > client
> > > > > > > > ID
> > > > > > > > > > without breaking older brokers. If we simply wanted to
> add a
> > > > > brand new
> > > > > > > > > > field to the request header, we can do it as a tagged
> field
> > > in
> > > > > request
> > > > > > > > > > header versions 2+.
> > > > > > > > > > JR27.2: Covered this too. We'd need a major version API
> > > > > compatibility
> > > > > > > > KIP.
> > > > > > > > > >
> > > > > > > > > > JR31: Yes. KIP updated.
> > > > > > > > > >
> > > > > > > > > > JR32: Yes. This is a minor inconvenience I feel. KIP
> updated.
> > > > > > > > > >
> > > > > > > > > > JR33: I don't see the value of a string comparison here.
> > > > > Personally,
> > > > > > > > I'm
> > > > > > > > > > happy with "assume".
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > Andrew
> > > > > > > > > >
> > > > > > > > > > On 2026/06/23 22:52:15 Jun Rao via dev wrote:
> > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > >
> > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > >
> > > > > > > > > > > JR27. The code that changed the request header parsing
> was
> > > > > > > > introduced in
> > > > > > > > > > > 2019 (
> > > > > > > > > >
> > > > > > > >
> > > > >
> > >
> https://urldefense.com/v3/__https://github.com/apache/kafka/pull/7372__;!!Ayb5sqE7!scbWbTEEm2o-Y3MBGi829H2cpMWPRyrF9g2CW3lmRHyRmgBU2MyoRif2mFJpnfmvQ2x7fF4LrAJXdwH86ERR$
> > > > > > > > > > ). I agree that fixing it
> > > > > > > > > > > now is too late. We should document the path forward
> for
> > > > > ApiVersion.
> > > > > > > > > > Could
> > > > > > > > > > > we answer at least the following questions in the
> > > > > Compatibility,
> > > > > > > > > > > Deprecation, and Migration Plan section?
> > > > > > > > > > > JR27.1 What happens to ApiVersion if we change the
> request
> > > > > header in
> > > > > > > > the
> > > > > > > > > > > future?
> > > > > > > > > > > JR27.2 What happens if we ever want to deprecate v2 of
> the
> > > > > request
> > > > > > > > > > header?
> > > > > > > > > > >
> > > > > > > > > > > JR28. The new MV needs to be covered in the
> Compatibility,
> > > > > > > > Deprecation,
> > > > > > > > > > and
> > > > > > > > > > > Migration Plan section.
> > > > > > > > > > >
> > > > > > > > > > > JR31. "If a connection uses the v3 request header in
> its
> > > first
> > > > > > > > request,
> > > > > > > > > > it
> > > > > > > > > > > must specify a non-zero client instance ID and it must
> > > specify
> > > > > the
> > > > > > > > same
> > > > > > > > > > > client instance ID for all subsequent requests."
> > > > > > > > > > > Do we do the same if the first request is v6 of
> ApiVersion?
> > > > > > > > > > >
> > > > > > > > > > > JR32. "For subsequent requests using an earlier
> version of
> > > the
> > > > > > > > request
> > > > > > > > > > > header, the client sends the client ID". This means
> that
> > > > > subsequent
> > > > > > > > > > > ApiVersion V6 requests will carry the non-null clientID
> > > > > > > > unnecessarily.
> > > > > > > > > > >
> > > > > > > > > > > JR33. "After this KIP, the broker will assume that the
> > > client
> > > > > ID
> > > > > > > > from the
> > > > > > > > > > > initial request applies to all subsequent requests on a
> > > > > connection,
> > > > > > > > and
> > > > > > > > > > it
> > > > > > > > > > > will ignore the client ID specified on any subsequent
> > > > > requests."
> > > > > > > > > > > Should the broker verify that the clientId from
> subsequent
> > > > > request
> > > > > > > > match
> > > > > > > > > > > the first cached one, if not null?
> > > > > > > > > > >
> > > > > > > > > > >  Jun
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Jun 23, 2026 at 6:05 AM Andrew Schofield <
> > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > Thanks for your reply.
> > > > > > > > > > > >
> > > > > > > > > > > > JR27: Unfortunately, I don't think this is
> acceptable. We
> > > > > would be
> > > > > > > > > > saying
> > > > > > > > > > > > that AK 4.5 clients can only connect to AK 4.5 or
> later
> > > > > brokers,
> > > > > > > > and
> > > > > > > > > > that
> > > > > > > > > > > > we'd create patch release for AK 4.0.x to AK 4.4.x.
> so
> > > AK 4.5
> > > > > > > > clients
> > > > > > > > > > could
> > > > > > > > > > > > connect to those too. We'd be preventing connection
> to
> > > AK 3.x
> > > > > > > > brokers
> > > > > > > > > > by AK
> > > > > > > > > > > > 4.5 clients. I don't see how we can break
> compatibility
> > > in a
> > > > > minor
> > > > > > > > > > release.
> > > > > > > > > > > > Here's the existing compatibility table:
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > >
> > >
> https://urldefense.com/v3/__https://kafka.apache.org/41/getting-started/compatibility/__;!!Ayb5sqE7!ppWU_jI9f7EY9DYwcbiOESSBG2TmPn9CHfLnVM5TaIMwWqHUbUbIiGre1GGKMr-HmelQlyP6ibUSyORCAgte$
> > > > > > > > > > > >
> > > > > > > > > > > > JR29: OK, makes sense to me.
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks,
> > > > > > > > > > > > Andrew
> > > > > > > > > > > >
> > > > > > > > > > > > On 2026/06/22 21:50:43 Jun Rao via dev wrote:
> > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > > >
> > > > > > > > > > > > > JR27. I am not sure I like the approach of pinning
> the
> > > > > header to
> > > > > > > > v2
> > > > > > > > > > for
> > > > > > > > > > > > > ApiVersionsRequest. This means that in the future,
> each
> > > > > change
> > > > > > > > to the
> > > > > > > > > > > > > request header must be duplicated in the request
> > > itself.
> > > > > Here is
> > > > > > > > an
> > > > > > > > > > > > > alternative. Note that to detect an unsupported
> > > > > > > > ApiVersionRequest, we
> > > > > > > > > > > > don't
> > > > > > > > > > > > > need to parse the full v2 request header. Parsing
> the
> > > > > first two
> > > > > > > > > > fields
> > > > > > > > > > > > > ApiKey and ApiVersion is enough. So, we could
> patch all
> > > > > the 4.x
> > > > > > > > > > releases
> > > > > > > > > > > > > with a change that short-circuits parsing the full
> > > request
> > > > > header
> > > > > > > > > > based
> > > > > > > > > > > > on
> > > > > > > > > > > > > the first two fields. Then, we recommend upgrading
> > > from the
> > > > > > > > latest
> > > > > > > > > > 4.x
> > > > > > > > > > > > > releases to future releases. This way, we can
> still let
> > > > > > > > > > > > ApiVersionsRequest
> > > > > > > > > > > > > depend on the request header for current and future
> > > > > changes.
> > > > > > > > > > > > >
> > > > > > > > > > > > > JR29. The simplest thing is to upgrade the KRaft
> RPCs
> > > too
> > > > > to be
> > > > > > > > > > > > consistent.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Jun
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Sat, Jun 20, 2026 at 3:38 AM Andrew Schofield <
> > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > Thanks for these insightful comments. I did
> > > prototype the
> > > > > > > > earlier
> > > > > > > > > > v2
> > > > > > > > > > > > > > request header with tagged fields variant. I
> have now
> > > > > > > > prototyped
> > > > > > > > > > the v3
> > > > > > > > > > > > > > request header variant.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > JR27: You were of course entirely correct that a
> new
> > > > > version of
> > > > > > > > > > > > > > ApiVersions request cannot use a request header
> > > which is
> > > > > not
> > > > > > > > > > > > > > binary-compatible with what has gone before. As a
> > > > > result, I
> > > > > > > > have
> > > > > > > > > > > > introduced
> > > > > > > > > > > > > > a new version of ApiVersions request which
> includes
> > > > > > > > > > ClientInstanceId
> > > > > > > > > > > > in the
> > > > > > > > > > > > > > request body but continues to use the v2 request
> > > header.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > JR28: Yes, we need a new metadata version, which
> is
> > > > > > > > provisionally
> > > > > > > > > > > > > > IBP_4_5_IV0. I'll update the KIP with the final
> value
> > > > > when it
> > > > > > > > is
> > > > > > > > > > > > assigned.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > JR29: I don't have any strong feelings on this. I
> > > > > suppose for
> > > > > > > > each
> > > > > > > > > > > > inter
> > > > > > > > > > > > > > broker RPC version that is bumped, we need to
> > > introduce
> > > > > an MV
> > > > > > > > > > check. We
> > > > > > > > > > > > > > cannot avoid this for RPCs which are also used by
> > > > > clients such
> > > > > > > > as
> > > > > > > > > > > > Fetch.
> > > > > > > > > > > > > > For purely inter-broker RPCs, we could just
> exempt
> > > them
> > > > > from
> > > > > > > > the
> > > > > > > > > > > > version
> > > > > > > > > > > > > > bump. What do you recommend here?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > JR30: Done. INVALID_REQUEST. I did consider
> > > permitting
> > > > > zero
> > > > > > > > client
> > > > > > > > > > > > > > instance ID for inter-broker connections, but I
> > > decided
> > > > > that I
> > > > > > > > > > > > preferred
> > > > > > > > > > > > > > not creating another rule.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On 2026/06/17 22:45:07 Andrew Schofield wrote:
> > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR27: I am familiar with KIP-511 and the
> oddness of
> > > > > > > > ApiVersions.
> > > > > > > > > > You
> > > > > > > > > > > > > > make an excellent point. I suspect that
> > > > > ApiVersionsRequest will
> > > > > > > > > > have
> > > > > > > > > > > > to be
> > > > > > > > > > > > > > limited to the v2 request header, just as it is
> > > > > restricted to
> > > > > > > > the
> > > > > > > > > > v0
> > > > > > > > > > > > > > response header.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I'll do some experimentation.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On 2026/06/17 17:35:17 Jun Rao via dev wrote:
> > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Thanks for the reply. A few more comments.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > JR27. It seems that we have a compatibility
> issue
> > > > > with
> > > > > > > > > > > > > > ApiVersionRequest v6
> > > > > > > > > > > > > > > > depending on RequestHeader v3. This happens
> when
> > > a
> > > > > new
> > > > > > > > client
> > > > > > > > > > > > issues
> > > > > > > > > > > > > > > > ApiVersionRequest v6 to an old broker (one
> that
> > > only
> > > > > > > > supports
> > > > > > > > > > > > > > > > ApiVersionRequest v5). The SocketServer in
> the
> > > > > broker will
> > > > > > > > > > first
> > > > > > > > > > > > try to
> > > > > > > > > > > > > > > > read the request header. It tries to find the
> > > header
> > > > > > > > version
> > > > > > > > > > from
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > request version. Since the broker doesn't
> know
> > > > > > > > > > ApiVersionRequest
> > > > > > > > > > > > v6, it
> > > > > > > > > > > > > > > > uses v2 to parse the request header.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > The v2's wire format for the request header
> is:
> > > > > ApiKey |
> > > > > > > > > > > > ApiVersion |
> > > > > > > > > > > > > > > > CorrelationId | ClientId |
> tagged-fields-varint
> > > > > > > > > > > > > > > > The v3's wire format for the request header
> is:
> > > > > ApiKey |
> > > > > > > > > > > > ApiVersion |
> > > > > > > > > > > > > > > > CorrelationId | ClientId |
> ClientInstanceId(16
> > > > > bytes) |
> > > > > > > > > > > > tagged-fields
> > > > > > > > > > > > > > varint
> > > > > > > > > > > > > > > > The first 4 fields are identical, allowing
> the
> > > > > broker to
> > > > > > > > parse
> > > > > > > > > > > > them.
> > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > broker then tries to read the
> > > tagged-fields-varint
> > > > > using
> > > > > > > > the
> > > > > > > > > > > > serialized
> > > > > > > > > > > > > > > > bytes intended for ClientInstanceId. This
> could
> > > lead
> > > > > to a
> > > > > > > > > > parsing
> > > > > > > > > > > > > > error and
> > > > > > > > > > > > > > > > raise an invalid request error. The broker
> will
> > > > > close the
> > > > > > > > > > > > connection
> > > > > > > > > > > > > > > > instead of sending a v0 response for
> > > > > ApiVersionRequest.
> > > > > > > > Then
> > > > > > > > > > the
> > > > > > > > > > > > client
> > > > > > > > > > > > > > > > will never be able to detect supported API
> > > versions
> > > > > on the
> > > > > > > > old
> > > > > > > > > > > > broker.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > The same problem didn't exist when
> > > ApiVersionRequest
> > > > > > > > changed
> > > > > > > > > > from
> > > > > > > > > > > > the
> > > > > > > > > > > > > > v1
> > > > > > > > > > > > > > > > request header to v2 because the wire format
> for
> > > v1
> > > > > is a
> > > > > > > > > > prefix of
> > > > > > > > > > > > v2.
> > > > > > > > > > > > > > This
> > > > > > > > > > > > > > > > problem exists for this KIP because the wire
> > > format
> > > > > of v2
> > > > > > > > is no
> > > > > > > > > > > > longer
> > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > prefix of v3.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > JR28. Since we are bumping up the version of
> > > inter
> > > > > broker
> > > > > > > > > > > > requests, we
> > > > > > > > > > > > > > need
> > > > > > > > > > > > > > > > to gate them by introducing a new MV.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > JR29. Could you specify whether the version
> for
> > > > > KRaft PRCs
> > > > > > > > > > will be
> > > > > > > > > > > > > > bumped
> > > > > > > > > > > > > > > > too?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > JR30. "If a connection uses the v3 request
> > > header in
> > > > > its
> > > > > > > > first
> > > > > > > > > > > > > > request, it
> > > > > > > > > > > > > > > > must specify a non-zero client instance ID"
> > > > > > > > > > > > > > > > Could we define the broker's behavior when a
> v3
> > > > > request
> > > > > > > > header
> > > > > > > > > > > > > > contains a 0
> > > > > > > > > > > > > > > > client instance ID?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Tue, Jun 16, 2026 at 1:25 AM Andrew
> Schofield
> > > <
> > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > JR26: Yes, I was considering open-ended
> version
> > > > > ranges.
> > > > > > > > I've
> > > > > > > > > > > > updated
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > KIP.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Now that we have a new request header
> version,
> > > I
> > > > > think
> > > > > > > > it's
> > > > > > > > > > safe
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > reintroduce the client ID optimisation.
> I've
> > > added
> > > > > that
> > > > > > > > into
> > > > > > > > > > the
> > > > > > > > > > > > KIP
> > > > > > > > > > > > > > also.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Let me know what you think.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On 2026/06/15 17:46:00 Jun Rao via dev
> wrote:
> > > > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Thanks for the reply. Just a minor
> comment.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > JR26. "The keys of the map are either
> single
> > > > > versions
> > > > > > > > like
> > > > > > > > > > "0"
> > > > > > > > > > > > or
> > > > > > > > > > > > > > closed
> > > > > > > > > > > > > > > > > > version ranges like "1-2"."
> > > > > > > > > > > > > > > > > > It will be useful to support open-ended
> > > > > versions. That
> > > > > > > > way,
> > > > > > > > > > > > "3":
> > > > > > > > > > > > > > "3"
> > > > > > > > > > > > > > > > > could
> > > > > > > > > > > > > > > > > > be "3+": "3". This part won't need to
> change
> > > in
> > > > > the
> > > > > > > > future
> > > > > > > > > > > > when we
> > > > > > > > > > > > > > bump
> > > > > > > > > > > > > > > > > up
> > > > > > > > > > > > > > > > > > the request version without changing the
> > > header.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Fri, Jun 12, 2026 at 2:12 PM Andrew
> > > Schofield
> > > > > <
> > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > JR25: I agree. I've changed to a
> > > > > headerVersions map
> > > > > > > > in
> > > > > > > > > > both
> > > > > > > > > > > > the
> > > > > > > > > > > > > > request
> > > > > > > > > > > > > > > > > > > and response schemas.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Let me know what you think.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On 2026/06/12 03:39:39 Jun Rao via dev
> > > wrote:
> > > > > > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Thanks for the updated KIP.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > JR25. I have some concerns about
> adding
> > > the
> > > > > > > > > > > > > > clientInstanceIdVersions
> > > > > > > > > > > > > > > > > > > field
> > > > > > > > > > > > > > > > > > > > to the schema. First of all, it only
> > > applies
> > > > > to
> > > > > > > > > > requests,
> > > > > > > > > > > > but
> > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > > > > responses. So, it's a bit weird to
> add
> > > it to
> > > > > the
> > > > > > > > > > general
> > > > > > > > > > > > > > schema.
> > > > > > > > > > > > > > > > > > > Secondly,
> > > > > > > > > > > > > > > > > > > > it's very specific to the new field
> > > added to
> > > > > the
> > > > > > > > > > request
> > > > > > > > > > > > > > header. If
> > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > > change the request header again in
> the
> > > > > future, we
> > > > > > > > need
> > > > > > > > > > > > another
> > > > > > > > > > > > > > way
> > > > > > > > > > > > > > > > > to map
> > > > > > > > > > > > > > > > > > > > request versions to the new header
> > > version.
> > > > > > > > Ideally, we
> > > > > > > > > > > > should
> > > > > > > > > > > > > > have a
> > > > > > > > > > > > > > > > > > > > generic way to map request versions
> to
> > > all
> > > > > future
> > > > > > > > > > header
> > > > > > > > > > > > > > versions.
> > > > > > > > > > > > > > > > > One
> > > > > > > > > > > > > > > > > > > > possibility is to introduce a
> > > headerVersion
> > > > > field
> > > > > > > > in
> > > > > > > > > > the
> > > > > > > > > > > > > > schema.
> > > > > > > > > > > > > > > > > Then,
> > > > > > > > > > > > > > > > > > > each
> > > > > > > > > > > > > > > > > > > > request/response can use this field
> to
> > > map
> > > > > its
> > > > > > > > > > versions to
> > > > > > > > > > > > the
> > > > > > > > > > > > > > header
> > > > > > > > > > > > > > > > > > > > versions.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Tue, Jun 9, 2026 at 4:55 AM Andrew
> > > > > Schofield <
> > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Hi Matthias,
> > > > > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I have change the version property
> for
> > > > > > > > introducing
> > > > > > > > > > client
> > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > ID
> > > > > > > > > > > > > > > > > > > into
> > > > > > > > > > > > > > > > > > > > > the request headers to be
> > > > > > > > `clientInstanceIdVersions`
> > > > > > > > > > > > which
> > > > > > > > > > > > > > is now
> > > > > > > > > > > > > > > > > an
> > > > > > > > > > > > > > > > > > > > > open-ended range, such as "3+",
> more
> > > > > closely
> > > > > > > > matching
> > > > > > > > > > > > what
> > > > > > > > > > > > > > we have
> > > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > flexible versions.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I also added a change to the
> > > > > > > > > > > > > > RebalanceConsumer.clientInstanceId
> > > > > > > > > > > > > > > > > method
> > > > > > > > > > > > > > > > > > > > > introduced in KIP-1306.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On 2026/06/03 18:31:06 "Matthias J.
> > > Sax"
> > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > Thanks Andrew.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >  From a KIP-714 perspective,
> this is
> > > a
> > > > > great
> > > > > > > > > > change,
> > > > > > > > > > > > as it
> > > > > > > > > > > > > > make
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > new
> > > > > > > > > > > > > > > > > > > > > > RPCs and client/broker
> cross-version
> > > > > > > > compatibility
> > > > > > > > > > > > clean.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > One question about your
> > > `DeleteGroups`
> > > > > RPC
> > > > > > > > example.
> > > > > > > > > > > > Should
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > new
> > > > > > > > > > > > > > > > > > > > > > version of the RPC say
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > "clientInstanceIdVersion":
> "3+",
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > ie, 3+ instead of 3? Similar for
> > > other
> > > > > request,
> > > > > > > > > > which
> > > > > > > > > > > > > > don't use
> > > > > > > > > > > > > > > > > `+`
> > > > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > > `clientInstanceIdVersion` field.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > -Matthias
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On 6/2/26 7:42 AM, Andrew
> Schofield
> > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > > Following on from the
> discussion
> > > in the
> > > > > > > > > > community,
> > > > > > > > > > > > and
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > difficulty
> > > > > > > > > > > > > > > > > > > > > of trying to accommodate the client
> > > > > instance ID
> > > > > > > > in a
> > > > > > > > > > > > tagged
> > > > > > > > > > > > > > field
> > > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > > > > acceptable complexity, I have made
> a
> > > > > significant
> > > > > > > > > > change
> > > > > > > > > > > > to
> > > > > > > > > > > > > > the KIP.
> > > > > > > > > > > > > > > > > > > Now, it
> > > > > > > > > > > > > > > > > > > > > introduces v3 of the request header
> > > > > containing
> > > > > > > > the
> > > > > > > > > > client
> > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > ID
> > > > > > > > > > > > > > > > > > > as a
> > > > > > > > > > > > > > > > > > > > > proper field.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > >
> > >
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/KAFKA/KIP-1313*3A*Client*instance*ID*in*all*request*headers__;JSsrKysrKys!!Ayb5sqE7!pUZS25PuTKdhiqvTGcwDKbclqpG8dFOzw2Ax9WxVM6Sb09PVQ0gl1i0gjlr2_Krr66agbuVC2qLGgUcg7vrW$
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Please review and let me know
> what
> > > you
> > > > > think.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > On 2026/05/28 21:51:01
> "Matthias J.
> > > > > Sax"
> > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > >> Thanks Andrew. I agree to the
> > > issue
> > > > > that
> > > > > > > > tagged
> > > > > > > > > > > > fields
> > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > optional.
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > >> Nevertheless, I find the
> proposed
> > > > > > > > compatibility
> > > > > > > > > > > > > > protocol too
> > > > > > > > > > > > > > > > > > > complex
> > > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > > >> unnecessary, and would still
> > > prefer a
> > > > > > > > version
> > > > > > > > > > bump
> > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > `GetTelemetrySubscriptionsRequest/Reponse`
> > > > > > > > to
> > > > > > > > > > clean
> > > > > > > > > > > > it
> > > > > > > > > > > > > > all
> > > > > > > > > > > > > > > > > up. --
> > > > > > > > > > > > > > > > > > > For
> > > > > > > > > > > > > > > > > > > > > > >> `PushTelemetryRequest` the
> > > argument
> > > > > from
> > > > > > > > above
> > > > > > > > > > > > applies,
> > > > > > > > > > > > > > so
> > > > > > > > > > > > > > > > > > > leaving it
> > > > > > > > > > > > > > > > > > > > > > >> untouched is ok.
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > >> I don't see why
> > > > > > > > > > `GetTelemetrySubscriptionsRequest`
> > > > > > > > > > > > > > would need
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > encode
> > > > > > > > > > > > > > > > > > > > > > >> the `clientInstandId` in it's
> > > request
> > > > > body.
> > > > > > > > > > Given
> > > > > > > > > > > > that
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > >> `clientInstanceId` is a random
> > > UUID,
> > > > > the
> > > > > > > > > > returned
> > > > > > > > > > > > > > subscription
> > > > > > > > > > > > > > > > > > > cannot
> > > > > > > > > > > > > > > > > > > > > > >> really depend on it. So why
> would
> > > we
> > > > > need to
> > > > > > > > > > send
> > > > > > > > > > > > it to
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > broker?
> > > > > > > > > > > > > > > > > > > > > > >> Right now, it's set to ZERO
> only
> > > for
> > > > > the
> > > > > > > > > > purpose to
> > > > > > > > > > > > get
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > broker to
> > > > > > > > > > > > > > > > > > > > > > >> assign a new UUID. But it has
> > > nothing
> > > > > to do
> > > > > > > > > > with the
> > > > > > > > > > > > > > actual
> > > > > > > > > > > > > > > > > "what
> > > > > > > > > > > > > > > > > > > > > > >> metrics should I send"
> question.
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > >> To be fair, KIP-714 lists
> > > > > > > > `client_instance_id`
> > > > > > > > > > as a
> > > > > > > > > > > > > > field that
> > > > > > > > > > > > > > > > > > > can be
> > > > > > > > > > > > > > > > > > > > > > >> used to define a subscription.
> > > But it
> > > > > seems
> > > > > > > > > > rather
> > > > > > > > > > > > > > useless in
> > > > > > > > > > > > > > > > > > > practice
> > > > > > > > > > > > > > > > > > > > > > >> to me? I a user defines a
> > > > > subscription, they
> > > > > > > > > > cannot
> > > > > > > > > > > > > > know the
> > > > > > > > > > > > > > > > > UUID.
> > > > > > > > > > > > > > > > > > > > > Thus,
> > > > > > > > > > > > > > > > > > > > > > >> I think we should actually
> drop
> > > > > supporting
> > > > > > > > > > > > > > > > > `client_instance_id`
> > > > > > > > > > > > > > > > > > > as a
> > > > > > > > > > > > > > > > > > > > > > >> "subscription matching
> > > parameter"? Of
> > > > > > > > course,
> > > > > > > > > > there
> > > > > > > > > > > > is a
> > > > > > > > > > > > > > > > > backward
> > > > > > > > > > > > > > > > > > > > > > >> compatibility question, but I
> > > think
> > > > > we can
> > > > > > > > > > address
> > > > > > > > > > > > > > this: if
> > > > > > > > > > > > > > > > > > > brokers
> > > > > > > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > > > > >> upgraded and they have an
> existing
> > > > > > > > > > > > `client_instance_id`
> > > > > > > > > > > > > > based
> > > > > > > > > > > > > > > > > > > > > > >> subscription defined, they
> could
> > > > > advertise
> > > > > > > > to
> > > > > > > > > > only
> > > > > > > > > > > > > > support
> > > > > > > > > > > > > > > > > v0, and
> > > > > > > > > > > > > > > > > > > > > they
> > > > > > > > > > > > > > > > > > > > > > >> should log a warning that this
> > > > > feature is
> > > > > > > > > > > > deprecated.
> > > > > > > > > > > > > > New
> > > > > > > > > > > > > > > > > brokers
> > > > > > > > > > > > > > > > > > > > > would
> > > > > > > > > > > > > > > > > > > > > > >> also not allow to use
> > > > > `client_instance_id`
> > > > > > > > any
> > > > > > > > > > > > longer to
> > > > > > > > > > > > > > > > > define a
> > > > > > > > > > > > > > > > > > > > > > >> subscription.
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > >> Similarly, for
> > > > > > > > > > `GetTelemetrySubscriptionsResponse`,
> > > > > > > > > > > > we
> > > > > > > > > > > > > > only
> > > > > > > > > > > > > > > > > need
> > > > > > > > > > > > > > > > > > > > > > >> `clientInstanceId` if the
> broker
> > > > > computes
> > > > > > > > the
> > > > > > > > > > UUID.
> > > > > > > > > > > > But
> > > > > > > > > > > > > > if we
> > > > > > > > > > > > > > > > > let
> > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > > >> client compute it, this field
> is
> > > not
> > > > > needed
> > > > > > > > any
> > > > > > > > > > > > longer.
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > >> -Matthias
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > >> On 5/28/26 1:21 AM, Andrew
> > > Schofield
> > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > >>> Hi Jun,
> > > > > > > > > > > > > > > > > > > > > > >>> Thanks for your response.
> > > > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > > > >>> JR24: I'll update the KIP
> > > shortly.
> > > > > Here's a
> > > > > > > > > > > > summary.
> > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > > various
> > > > > > > > > > > > > > > > > > > > > modern group protocol heartbeat
> > > requests
> > > > > encode
> > > > > > > > the
> > > > > > > > > > > > member
> > > > > > > > > > > > > > ID as a
> > > > > > > > > > > > > > > > > > > string
> > > > > > > > > > > > > > > > > > > > > for historical reasons, even though
> > > it's in
> > > > > > > > practice
> > > > > > > > > > a
> > > > > > > > > > > > UUID.
> > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > > Apache
> > > > > > > > > > > > > > > > > > > > > Kafka Java client happens to use
> > > > > > > > > > > > > > org.apache.kafka.common.Uuid to
> > > > > > > > > > > > > > > > > > > create the
> > > > > > > > > > > > > > > > > > > > > member ID and convert it into a
> string.
> > > > > This
> > > > > > > > means
> > > > > > > > > > that
> > > > > > > > > > > > when
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > clientInstanceId is converted into
> a
> > > > > string, its
> > > > > > > > > > encoding
> > > > > > > > > > > > > > matches
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > member ID and it all lines up.
> However,
> > > > > there are
> > > > > > > > > > other
> > > > > > > > > > > > ways
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > encode
> > > > > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > > > > UUID into a string and I know for a
> > > fact
> > > > > that the
> > > > > > > > > > > > librdkafka
> > > > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > > > does it
> > > > > > > > > > > > > > > > > > > > > differently.
> > > > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > > > >>> Thanks,
> > > > > > > > > > > > > > > > > > > > > > >>> Andrew
> > > > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > > > >>> On 2026/05/27 17:11:25 Jun
> Rao
> > > via
> > > > > dev
> > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > >>>> Hi, Andrew,
> > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > >>>> Thanks for the reply. One
> more
> > > > > comment.
> > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > >>>> JR24. "The alignment of
> other
> > > > > identifiers
> > > > > > > > is
> > > > > > > > > > by
> > > > > > > > > > > > > > convention
> > > > > > > > > > > > > > > > > (and
> > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > Java
> > > > > > > > > > > > > > > > > > > > > > >>>> client will follow the
> > > convention)
> > > > > rather
> > > > > > > > than
> > > > > > > > > > > > > > mandate."
> > > > > > > > > > > > > > > > > Could
> > > > > > > > > > > > > > > > > > > you
> > > > > > > > > > > > > > > > > > > > > describe
> > > > > > > > > > > > > > > > > > > > > > >>>> the convention to convert a
> > > > > > > > clientInstanceId
> > > > > > > > > > > > (UUID)
> > > > > > > > > > > > > > to a
> > > > > > > > > > > > > > > > > > > memberId
> > > > > > > > > > > > > > > > > > > > > (String)?
> > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > >>>> Jun
> > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > >>>> On Tue, May 19, 2026 at
> 2:36 AM
> > > > > Andrew
> > > > > > > > > > Schofield <
> > > > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > >>>>> 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 <
> > > > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > >>>>>> 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 <
> > > > > > > > > > > > > > > > > > > > > > >>>>>>> schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> 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 <
> > > > > > > > > > > > > > > > > > > > > > >>>>>>> schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> 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
> > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] KIP-1313: Client instance ID in all request headers

[Andrew Schofield <sc...@apache.org>]

Hi Jun,
Thanks for your reply.

JR37: Unlike with clientId where space is saved by not transmitting it on every request, there's nothing to be gained by omitting clientInstanceId on later requests. I prefer to leave it as is.

JR38: OK, I've updated those paragraphs in the KIP to exclude the reserved UUIDs.

Thanks,
Andrew

On 2026/08/03 20:23:39 Jun Rao via dev wrote:
> Hi, Andrew,
> 
> Thanks for the reply.
> 
> JR37. Will it be better to require ClientInstanceId only on the first
> request, to be consistent with clientId?
> 
> JR38. "must specify a non-zero client instance ID". one_uuid is also a
> reserved one in the Uuid class. Should we exclude that one too?
> 
> Jun
> 
> On Fri, Jul 31, 2026 at 9:10 AM Andrew Schofield <sc...@apache.org>
> wrote:
> 
> > Hi Jun,
> > Thanks for the reply and sorry for the delay. Lots of 4.4 stuff got in the
> > way.
> >
> > JR34: EligibleLeaderReplicasVersion and KRaftVersion also use ApiVersion
> > to negotiate the RPC versions. I do not believe we need to bump up other
> > feature versions as a result of the RPC version bumps in this KIP.
> >
> > JR35: Yes, good catch. In order to handle client ID-based quotas for
> > forwarded requests, it will be necessary to populate the client ID in the
> > forwarded request header. KIP updated.
> >
> > JR36: I hadn't considered MV to be a feature version, but I understand.
> > KIP updated.
> >
> > Thanks,
> > Andrew
> >
> > On 2026/06/29 16:23:09 Jun Rao via dev wrote:
> > > Hi, Andrew,
> > >
> > > Thanks for the reply.
> > >
> > > JR34. Transaction coordinator uses ApiVersion to negotiate the PRC
> > > versions. Therefore, if there is no functional change, there is no need
> > to
> > > bump the TV version. I am not sure about EligibleLeaderReplicasVersion
> > > and KRaftVersion.
> > > It would be useful to have the experts chime in.
> > >
> > > JR35. Envelope/forwarding interaction: When a broker forwards a client
> > > request to the controller via EnvelopeUtils
> > (parseForwardedRequestHeader),
> > > the inner header may have its clientId optimized to null. Some quota
> > > enforcement (e.g. controller mutation) may depend on the non-null
> > clientId.
> > > The per-connection caching occurs on the original client↔broker
> > connection, not
> > > the broker↔controller one. Should the forwarded request preserve the
> > > non-null resolved (cached) client.id?
> > >
> > > JR36. "This KIP does not need to introduce any feature version bumps."
> > This
> > > is not very accurate since MV is a feature version and is bumped.
> > >
> > > Jun
> > >
> > >
> > > On Fri, Jun 26, 2026 at 12:42 AM Andrew Schofield <schofielaj@apache.org
> > >
> > > wrote:
> > >
> > > > Hi Jun,
> > > > I've updated the KIP.
> > > >
> > > > JS34: I don't believe that we need to introduce any new feature
> > versions
> > > > for this KIP. For example, we do not need a new ShareVersion since that
> > > > enabled share groups (SV_1) and controls the versioning of the records
> > on
> > > > the internal topics (SV_2). I think the same applies for the others. I
> > > > understand GroupVersion and StreamsVersion, and I think they follow the
> > > > same reasoning as ShareVersion. I don't know TransactionVersion or
> > > > EligibleLeaderReplicasVersion, so let me know whether those are
> > different
> > > > in this regard.
> > > >
> > > > Thanks,
> > > > Andrew
> > > >
> > > > On 2026/06/25 21:32:27 Andrew Schofield wrote:
> > > > > Hi Jun,
> > > > > Thanks for the reply.
> > > > >
> > > > > JR27: Yes, makes sense. So request header v3 is binary-compatible
> > with
> > > > request header v2.
> > > > >
> > > > > JS34: Yes, I think so.
> > > > >
> > > > > I'll update the KIP tomorrow morning.
> > > > >
> > > > > Thanks,
> > > > > Andrew
> > > > >
> > > > > On 2026/06/25 20:23:57 Jun Rao via dev wrote:
> > > > > > Hi, Andrew,
> > > > > >
> > > > > > Thanks for the reply.
> > > > > >
> > > > > > JR27. I was thinking of the following, which is slightly different
> > from
> > > > > > what you described.
> > > > > > * Bump RequestHeader to v3, and introduce ClientInstanceId as a
> > tagged
> > > > > > field for versions 3+ and change the semantic of the existing field
> > > > > > clientId (only need to be populated by the first request).
> > > > > > * Bump the request versions for all RPCs including ApiVersion and
> > map
> > > > to
> > > > > > the new version to use v3 of RequestHeader.
> > > > > > * On the server side, when a new request version is seen, we
> > enforce
> > > > the
> > > > > > presence of ClientInstanceId and reject the request if it is
> > missing.
> > > > > > Essentially, treat it as a required field. We also cache the
> > clientId
> > > > from
> > > > > > the first request and ignore it from subsequent ones.
> > > > > > * We would introduce OffsetDelete v1 as the first flexible version
> > so
> > > > that
> > > > > > it uses the v3 request header.
> > > > > > * We would update PushTelemetry and GetTelemetrySubscriptions as
> > > > described
> > > > > > in the KIP and the ClientInstanceId would move to the request
> > header.
> > > > > >
> > > > > > In the future, if we want to add a new truly optional field to
> > > > > > RequestHeader, we can continue adding it as a tagged field without
> > > > bumping
> > > > > > up the request version. To add a required field, we will add it as
> > a
> > > > tagged
> > > > > > field but force a version bump to all requests.
> > > > > >
> > > > > > The benefit of this approach is that (1) it's compatible with the
> > > > format of
> > > > > > the old request header; (2) it avoids duplicating new fields; and
> > (3)
> > > > there
> > > > > > is no constraint on deprecating the old request header. It's
> > slightly
> > > > weird
> > > > > > to bump up the version when adding a tagged field. But it still
> > seems
> > > > > > better than the alternatives.
> > > > > >
> > > > > > JR34. Since we now have different feature versions gating different
> > > > RPCs,
> > > > > > should we bump up GV, TV, etc., too?
> > > > > >
> > > > > > Jun
> > > > > >
> > > > > > On Thu, Jun 25, 2026 at 10:37 AM Andrew Schofield <
> > > > schofielaj@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Jun,
> > > > > > > Thanks for the reply.
> > > > > > >
> > > > > > > JR27.1: What if we want to add non-optional fields to the request
> > > > header
> > > > > > > in the future? I think that such fields would be by definition
> > future
> > > > > > > fields which would not be understood by existing brokers. For
> > > > serialization
> > > > > > > reasons, I think we would use version 2+ tagged fields and the
> > > > requirement
> > > > > > > for non-optionality would be enforced by code, rather than by the
> > > > protocol
> > > > > > > schema. This avoids the field duplication.
> > > > > > >
> > > > > > > JR27.2: Yes, I don't like it, but when we inevitably do another
> > > > KIP-896 to
> > > > > > > remove support for ancient parts of the protocol, it's going to
> > be
> > > > another
> > > > > > > KIP. That's all I meant.
> > > > > > >
> > > > > > > If I understand your proposal correctly compared with the
> > existing
> > > > KIP
> > > > > > > text, it would look like this:
> > > > > > > * Remove RequestHeader v3, and introduce ClientInstanceId as a
> > tagged
> > > > > > > field for versions 2+.
> > > > > > > * Bump the request versions for all RPCs. We'd update the request
> > > > JSON
> > > > > > > schemas with something like "ClientInstanceIdVersions": "X+".
> > This
> > > > would
> > > > > > > mean that the request would only be properly formed if it had the
> > > > > > > ClientInstanceId present, and would also mean that ClientId
> > could be
> > > > null
> > > > > > > for non-initial requests on each connection.
> > > > > > > * We would create ApiVersions v6, simply as a matter of the
> > bumping
> > > > of
> > > > > > > request versions for all RPCs, but its schema would be unchanged
> > > > from v5.
> > > > > > > * We would introduce OffsetDelete v1 as the first flexible
> > version
> > > > so that
> > > > > > > it uses the v2 request header.
> > > > > > > * We would update PushTelemetry and GetTelemetrySubscriptions as
> > > > described
> > > > > > > in the KIP and the ClientInstanceId would move to the request
> > header.
> > > > > > >
> > > > > > > I think that works roughly the same as what we have today. I
> > don't
> > > > really
> > > > > > > like the mandatory nature of the tagged field, but then I don't
> > > > really like
> > > > > > > the way that ApiVersions is pegged on a historical request header
> > > > version.
> > > > > > >
> > > > > > > Do I have this correct? If so, I can update the KIP accordingly.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Andrew
> > > > > > >
> > > > > > > On 2026/06/24 23:40:06 Jun Rao via dev wrote:
> > > > > > > > Hi, Andrew,
> > > > > > > >
> > > > > > > > Thanks for the reply.
> > > > > > > >
> > > > > > > > JR27.1 What if we want to add non-optional fields to the
> > request
> > > > header
> > > > > > > in
> > > > > > > > the future? The choice I see is duplicating the field in the
> > new
> > > > request
> > > > > > > > header and the new ApiVersion request. But it's not very clean.
> > > > > > > > JR27.2 Requiring a major version API compatibility KIP is also
> > a
> > > > bit
> > > > > > > > awkward.
> > > > > > > >
> > > > > > > > Here is yet another proposal. We add the ClientInstanceId to
> > the
> > > > request
> > > > > > > > header as a tagged field and also bump up all request versions.
> > > > This
> > > > > > > avoids
> > > > > > > > the header compatibility issue in SocketServer. The bumped-up
> > > > version
> > > > > > > > signals that the new field is actually required. On the server
> > > > side, when
> > > > > > > > receiving the new version of a request, we verify that the
> > > > > > > ClientInstanceId
> > > > > > > > field exists. If it's not present, we reject the request. This
> > > > will be
> > > > > > > the
> > > > > > > > convention for adding future required fields to the header.
> > > > Compared to
> > > > > > > the
> > > > > > > > current proposal, this avoids duplicating the field between
> > request
> > > > > > > header
> > > > > > > > and ApiVersionRequest, and it provides a path for deprecating
> > the
> > > > older
> > > > > > > > version of the request header. What do you think?
> > > > > > > >
> > > > > > > > Jun
> > > > > > > >
> > > > > > > > On Wed, Jun 24, 2026 at 2:15 AM Andrew Schofield <
> > > > schofielaj@apache.org>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi Jun,
> > > > > > > > > Thanks for the reply.
> > > > > > > > >
> > > > > > > > > JR27: Yes, I enhanced that section of the KIP.
> > > > > > > > > JR27.1: This KIP was unusual because we wanted to add a
> > concept
> > > > which
> > > > > > > > > existed in the KIP-714 RPCs to the request header,
> > complicating
> > > > the
> > > > > > > > > behavior of those RPCs, AND we wanted to change the handling
> > of
> > > > client
> > > > > > > ID
> > > > > > > > > without breaking older brokers. If we simply wanted to add a
> > > > brand new
> > > > > > > > > field to the request header, we can do it as a tagged field
> > in
> > > > request
> > > > > > > > > header versions 2+.
> > > > > > > > > JR27.2: Covered this too. We'd need a major version API
> > > > compatibility
> > > > > > > KIP.
> > > > > > > > >
> > > > > > > > > JR31: Yes. KIP updated.
> > > > > > > > >
> > > > > > > > > JR32: Yes. This is a minor inconvenience I feel. KIP updated.
> > > > > > > > >
> > > > > > > > > JR33: I don't see the value of a string comparison here.
> > > > Personally,
> > > > > > > I'm
> > > > > > > > > happy with "assume".
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Andrew
> > > > > > > > >
> > > > > > > > > On 2026/06/23 22:52:15 Jun Rao via dev wrote:
> > > > > > > > > > Hi, Andrew,
> > > > > > > > > >
> > > > > > > > > > Thanks for the reply.
> > > > > > > > > >
> > > > > > > > > > JR27. The code that changed the request header parsing was
> > > > > > > introduced in
> > > > > > > > > > 2019 (
> > > > > > > > >
> > > > > > >
> > > >
> > https://urldefense.com/v3/__https://github.com/apache/kafka/pull/7372__;!!Ayb5sqE7!scbWbTEEm2o-Y3MBGi829H2cpMWPRyrF9g2CW3lmRHyRmgBU2MyoRif2mFJpnfmvQ2x7fF4LrAJXdwH86ERR$
> > > > > > > > > ). I agree that fixing it
> > > > > > > > > > now is too late. We should document the path forward for
> > > > ApiVersion.
> > > > > > > > > Could
> > > > > > > > > > we answer at least the following questions in the
> > > > Compatibility,
> > > > > > > > > > Deprecation, and Migration Plan section?
> > > > > > > > > > JR27.1 What happens to ApiVersion if we change the request
> > > > header in
> > > > > > > the
> > > > > > > > > > future?
> > > > > > > > > > JR27.2 What happens if we ever want to deprecate v2 of the
> > > > request
> > > > > > > > > header?
> > > > > > > > > >
> > > > > > > > > > JR28. The new MV needs to be covered in the Compatibility,
> > > > > > > Deprecation,
> > > > > > > > > and
> > > > > > > > > > Migration Plan section.
> > > > > > > > > >
> > > > > > > > > > JR31. "If a connection uses the v3 request header in its
> > first
> > > > > > > request,
> > > > > > > > > it
> > > > > > > > > > must specify a non-zero client instance ID and it must
> > specify
> > > > the
> > > > > > > same
> > > > > > > > > > client instance ID for all subsequent requests."
> > > > > > > > > > Do we do the same if the first request is v6 of ApiVersion?
> > > > > > > > > >
> > > > > > > > > > JR32. "For subsequent requests using an earlier version of
> > the
> > > > > > > request
> > > > > > > > > > header, the client sends the client ID". This means that
> > > > subsequent
> > > > > > > > > > ApiVersion V6 requests will carry the non-null clientID
> > > > > > > unnecessarily.
> > > > > > > > > >
> > > > > > > > > > JR33. "After this KIP, the broker will assume that the
> > client
> > > > ID
> > > > > > > from the
> > > > > > > > > > initial request applies to all subsequent requests on a
> > > > connection,
> > > > > > > and
> > > > > > > > > it
> > > > > > > > > > will ignore the client ID specified on any subsequent
> > > > requests."
> > > > > > > > > > Should the broker verify that the clientId from subsequent
> > > > request
> > > > > > > match
> > > > > > > > > > the first cached one, if not null?
> > > > > > > > > >
> > > > > > > > > >  Jun
> > > > > > > > > >
> > > > > > > > > > On Tue, Jun 23, 2026 at 6:05 AM Andrew Schofield <
> > > > > > > schofielaj@apache.org>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi Jun,
> > > > > > > > > > > Thanks for your reply.
> > > > > > > > > > >
> > > > > > > > > > > JR27: Unfortunately, I don't think this is acceptable. We
> > > > would be
> > > > > > > > > saying
> > > > > > > > > > > that AK 4.5 clients can only connect to AK 4.5 or later
> > > > brokers,
> > > > > > > and
> > > > > > > > > that
> > > > > > > > > > > we'd create patch release for AK 4.0.x to AK 4.4.x. so
> > AK 4.5
> > > > > > > clients
> > > > > > > > > could
> > > > > > > > > > > connect to those too. We'd be preventing connection to
> > AK 3.x
> > > > > > > brokers
> > > > > > > > > by AK
> > > > > > > > > > > 4.5 clients. I don't see how we can break compatibility
> > in a
> > > > minor
> > > > > > > > > release.
> > > > > > > > > > > Here's the existing compatibility table:
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > >
> > https://urldefense.com/v3/__https://kafka.apache.org/41/getting-started/compatibility/__;!!Ayb5sqE7!ppWU_jI9f7EY9DYwcbiOESSBG2TmPn9CHfLnVM5TaIMwWqHUbUbIiGre1GGKMr-HmelQlyP6ibUSyORCAgte$
> > > > > > > > > > >
> > > > > > > > > > > JR29: OK, makes sense to me.
> > > > > > > > > > >
> > > > > > > > > > > Thanks,
> > > > > > > > > > > Andrew
> > > > > > > > > > >
> > > > > > > > > > > On 2026/06/22 21:50:43 Jun Rao via dev wrote:
> > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks for the reply.
> > > > > > > > > > > >
> > > > > > > > > > > > JR27. I am not sure I like the approach of pinning the
> > > > header to
> > > > > > > v2
> > > > > > > > > for
> > > > > > > > > > > > ApiVersionsRequest. This means that in the future, each
> > > > change
> > > > > > > to the
> > > > > > > > > > > > request header must be duplicated in the request
> > itself.
> > > > Here is
> > > > > > > an
> > > > > > > > > > > > alternative. Note that to detect an unsupported
> > > > > > > ApiVersionRequest, we
> > > > > > > > > > > don't
> > > > > > > > > > > > need to parse the full v2 request header. Parsing the
> > > > first two
> > > > > > > > > fields
> > > > > > > > > > > > ApiKey and ApiVersion is enough. So, we could patch all
> > > > the 4.x
> > > > > > > > > releases
> > > > > > > > > > > > with a change that short-circuits parsing the full
> > request
> > > > header
> > > > > > > > > based
> > > > > > > > > > > on
> > > > > > > > > > > > the first two fields. Then, we recommend upgrading
> > from the
> > > > > > > latest
> > > > > > > > > 4.x
> > > > > > > > > > > > releases to future releases. This way, we can still let
> > > > > > > > > > > ApiVersionsRequest
> > > > > > > > > > > > depend on the request header for current and future
> > > > changes.
> > > > > > > > > > > >
> > > > > > > > > > > > JR29. The simplest thing is to upgrade the KRaft RPCs
> > too
> > > > to be
> > > > > > > > > > > consistent.
> > > > > > > > > > > >
> > > > > > > > > > > > Jun
> > > > > > > > > > > >
> > > > > > > > > > > > On Sat, Jun 20, 2026 at 3:38 AM Andrew Schofield <
> > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > Thanks for these insightful comments. I did
> > prototype the
> > > > > > > earlier
> > > > > > > > > v2
> > > > > > > > > > > > > request header with tagged fields variant. I have now
> > > > > > > prototyped
> > > > > > > > > the v3
> > > > > > > > > > > > > request header variant.
> > > > > > > > > > > > >
> > > > > > > > > > > > > JR27: You were of course entirely correct that a new
> > > > version of
> > > > > > > > > > > > > ApiVersions request cannot use a request header
> > which is
> > > > not
> > > > > > > > > > > > > binary-compatible with what has gone before. As a
> > > > result, I
> > > > > > > have
> > > > > > > > > > > introduced
> > > > > > > > > > > > > a new version of ApiVersions request which includes
> > > > > > > > > ClientInstanceId
> > > > > > > > > > > in the
> > > > > > > > > > > > > request body but continues to use the v2 request
> > header.
> > > > > > > > > > > > >
> > > > > > > > > > > > > JR28: Yes, we need a new metadata version, which is
> > > > > > > provisionally
> > > > > > > > > > > > > IBP_4_5_IV0. I'll update the KIP with the final value
> > > > when it
> > > > > > > is
> > > > > > > > > > > assigned.
> > > > > > > > > > > > >
> > > > > > > > > > > > > JR29: I don't have any strong feelings on this. I
> > > > suppose for
> > > > > > > each
> > > > > > > > > > > inter
> > > > > > > > > > > > > broker RPC version that is bumped, we need to
> > introduce
> > > > an MV
> > > > > > > > > check. We
> > > > > > > > > > > > > cannot avoid this for RPCs which are also used by
> > > > clients such
> > > > > > > as
> > > > > > > > > > > Fetch.
> > > > > > > > > > > > > For purely inter-broker RPCs, we could just exempt
> > them
> > > > from
> > > > > > > the
> > > > > > > > > > > version
> > > > > > > > > > > > > bump. What do you recommend here?
> > > > > > > > > > > > >
> > > > > > > > > > > > > JR30: Done. INVALID_REQUEST. I did consider
> > permitting
> > > > zero
> > > > > > > client
> > > > > > > > > > > > > instance ID for inter-broker connections, but I
> > decided
> > > > that I
> > > > > > > > > > > preferred
> > > > > > > > > > > > > not creating another rule.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > Andrew
> > > > > > > > > > > > >
> > > > > > > > > > > > > On 2026/06/17 22:45:07 Andrew Schofield wrote:
> > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > JR27: I am familiar with KIP-511 and the oddness of
> > > > > > > ApiVersions.
> > > > > > > > > You
> > > > > > > > > > > > > make an excellent point. I suspect that
> > > > ApiVersionsRequest will
> > > > > > > > > have
> > > > > > > > > > > to be
> > > > > > > > > > > > > limited to the v2 request header, just as it is
> > > > restricted to
> > > > > > > the
> > > > > > > > > v0
> > > > > > > > > > > > > response header.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I'll do some experimentation.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On 2026/06/17 17:35:17 Jun Rao via dev wrote:
> > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Thanks for the reply. A few more comments.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR27. It seems that we have a compatibility issue
> > > > with
> > > > > > > > > > > > > ApiVersionRequest v6
> > > > > > > > > > > > > > > depending on RequestHeader v3. This happens when
> > a
> > > > new
> > > > > > > client
> > > > > > > > > > > issues
> > > > > > > > > > > > > > > ApiVersionRequest v6 to an old broker (one that
> > only
> > > > > > > supports
> > > > > > > > > > > > > > > ApiVersionRequest v5). The SocketServer in the
> > > > broker will
> > > > > > > > > first
> > > > > > > > > > > try to
> > > > > > > > > > > > > > > read the request header. It tries to find the
> > header
> > > > > > > version
> > > > > > > > > from
> > > > > > > > > > > the
> > > > > > > > > > > > > > > request version. Since the broker doesn't know
> > > > > > > > > ApiVersionRequest
> > > > > > > > > > > v6, it
> > > > > > > > > > > > > > > uses v2 to parse the request header.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > The v2's wire format for the request header is:
> > > > ApiKey |
> > > > > > > > > > > ApiVersion |
> > > > > > > > > > > > > > > CorrelationId | ClientId | tagged-fields-varint
> > > > > > > > > > > > > > > The v3's wire format for the request header is:
> > > > ApiKey |
> > > > > > > > > > > ApiVersion |
> > > > > > > > > > > > > > > CorrelationId | ClientId | ClientInstanceId(16
> > > > bytes) |
> > > > > > > > > > > tagged-fields
> > > > > > > > > > > > > varint
> > > > > > > > > > > > > > > The first 4 fields are identical, allowing the
> > > > broker to
> > > > > > > parse
> > > > > > > > > > > them.
> > > > > > > > > > > > > The
> > > > > > > > > > > > > > > broker then tries to read the
> > tagged-fields-varint
> > > > using
> > > > > > > the
> > > > > > > > > > > serialized
> > > > > > > > > > > > > > > bytes intended for ClientInstanceId. This could
> > lead
> > > > to a
> > > > > > > > > parsing
> > > > > > > > > > > > > error and
> > > > > > > > > > > > > > > raise an invalid request error. The broker will
> > > > close the
> > > > > > > > > > > connection
> > > > > > > > > > > > > > > instead of sending a v0 response for
> > > > ApiVersionRequest.
> > > > > > > Then
> > > > > > > > > the
> > > > > > > > > > > client
> > > > > > > > > > > > > > > will never be able to detect supported API
> > versions
> > > > on the
> > > > > > > old
> > > > > > > > > > > broker.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > The same problem didn't exist when
> > ApiVersionRequest
> > > > > > > changed
> > > > > > > > > from
> > > > > > > > > > > the
> > > > > > > > > > > > > v1
> > > > > > > > > > > > > > > request header to v2 because the wire format for
> > v1
> > > > is a
> > > > > > > > > prefix of
> > > > > > > > > > > v2.
> > > > > > > > > > > > > This
> > > > > > > > > > > > > > > problem exists for this KIP because the wire
> > format
> > > > of v2
> > > > > > > is no
> > > > > > > > > > > longer
> > > > > > > > > > > > > a
> > > > > > > > > > > > > > > prefix of v3.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR28. Since we are bumping up the version of
> > inter
> > > > broker
> > > > > > > > > > > requests, we
> > > > > > > > > > > > > need
> > > > > > > > > > > > > > > to gate them by introducing a new MV.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR29. Could you specify whether the version for
> > > > KRaft PRCs
> > > > > > > > > will be
> > > > > > > > > > > > > bumped
> > > > > > > > > > > > > > > too?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > JR30. "If a connection uses the v3 request
> > header in
> > > > its
> > > > > > > first
> > > > > > > > > > > > > request, it
> > > > > > > > > > > > > > > must specify a non-zero client instance ID"
> > > > > > > > > > > > > > > Could we define the broker's behavior when a v3
> > > > request
> > > > > > > header
> > > > > > > > > > > > > contains a 0
> > > > > > > > > > > > > > > client instance ID?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Tue, Jun 16, 2026 at 1:25 AM Andrew Schofield
> > <
> > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > JR26: Yes, I was considering open-ended version
> > > > ranges.
> > > > > > > I've
> > > > > > > > > > > updated
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > KIP.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Now that we have a new request header version,
> > I
> > > > think
> > > > > > > it's
> > > > > > > > > safe
> > > > > > > > > > > to
> > > > > > > > > > > > > > > > reintroduce the client ID optimisation. I've
> > added
> > > > that
> > > > > > > into
> > > > > > > > > the
> > > > > > > > > > > KIP
> > > > > > > > > > > > > also.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Let me know what you think.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On 2026/06/15 17:46:00 Jun Rao via dev wrote:
> > > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Thanks for the reply. Just a minor comment.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > JR26. "The keys of the map are either single
> > > > versions
> > > > > > > like
> > > > > > > > > "0"
> > > > > > > > > > > or
> > > > > > > > > > > > > closed
> > > > > > > > > > > > > > > > > version ranges like "1-2"."
> > > > > > > > > > > > > > > > > It will be useful to support open-ended
> > > > versions. That
> > > > > > > way,
> > > > > > > > > > > "3":
> > > > > > > > > > > > > "3"
> > > > > > > > > > > > > > > > could
> > > > > > > > > > > > > > > > > be "3+": "3". This part won't need to change
> > in
> > > > the
> > > > > > > future
> > > > > > > > > > > when we
> > > > > > > > > > > > > bump
> > > > > > > > > > > > > > > > up
> > > > > > > > > > > > > > > > > the request version without changing the
> > header.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Fri, Jun 12, 2026 at 2:12 PM Andrew
> > Schofield
> > > > <
> > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Hi Jun,
> > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > JR25: I agree. I've changed to a
> > > > headerVersions map
> > > > > > > in
> > > > > > > > > both
> > > > > > > > > > > the
> > > > > > > > > > > > > request
> > > > > > > > > > > > > > > > > > and response schemas.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Let me know what you think.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On 2026/06/12 03:39:39 Jun Rao via dev
> > wrote:
> > > > > > > > > > > > > > > > > > > Hi, Andrew,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Thanks for the updated KIP.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > JR25. I have some concerns about adding
> > the
> > > > > > > > > > > > > clientInstanceIdVersions
> > > > > > > > > > > > > > > > > > field
> > > > > > > > > > > > > > > > > > > to the schema. First of all, it only
> > applies
> > > > to
> > > > > > > > > requests,
> > > > > > > > > > > but
> > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > > > responses. So, it's a bit weird to add
> > it to
> > > > the
> > > > > > > > > general
> > > > > > > > > > > > > schema.
> > > > > > > > > > > > > > > > > > Secondly,
> > > > > > > > > > > > > > > > > > > it's very specific to the new field
> > added to
> > > > the
> > > > > > > > > request
> > > > > > > > > > > > > header. If
> > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > > > change the request header again in the
> > > > future, we
> > > > > > > need
> > > > > > > > > > > another
> > > > > > > > > > > > > way
> > > > > > > > > > > > > > > > to map
> > > > > > > > > > > > > > > > > > > request versions to the new header
> > version.
> > > > > > > Ideally, we
> > > > > > > > > > > should
> > > > > > > > > > > > > have a
> > > > > > > > > > > > > > > > > > > generic way to map request versions to
> > all
> > > > future
> > > > > > > > > header
> > > > > > > > > > > > > versions.
> > > > > > > > > > > > > > > > One
> > > > > > > > > > > > > > > > > > > possibility is to introduce a
> > headerVersion
> > > > field
> > > > > > > in
> > > > > > > > > the
> > > > > > > > > > > > > schema.
> > > > > > > > > > > > > > > > Then,
> > > > > > > > > > > > > > > > > > each
> > > > > > > > > > > > > > > > > > > request/response can use this field to
> > map
> > > > its
> > > > > > > > > versions to
> > > > > > > > > > > the
> > > > > > > > > > > > > header
> > > > > > > > > > > > > > > > > > > versions.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Jun
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Tue, Jun 9, 2026 at 4:55 AM Andrew
> > > > Schofield <
> > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Hi Matthias,
> > > > > > > > > > > > > > > > > > > > Thanks for your response.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I have change the version property for
> > > > > > > introducing
> > > > > > > > > client
> > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > ID
> > > > > > > > > > > > > > > > > > into
> > > > > > > > > > > > > > > > > > > > the request headers to be
> > > > > > > `clientInstanceIdVersions`
> > > > > > > > > > > which
> > > > > > > > > > > > > is now
> > > > > > > > > > > > > > > > an
> > > > > > > > > > > > > > > > > > > > open-ended range, such as "3+", more
> > > > closely
> > > > > > > matching
> > > > > > > > > > > what
> > > > > > > > > > > > > we have
> > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > flexible versions.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I also added a change to the
> > > > > > > > > > > > > RebalanceConsumer.clientInstanceId
> > > > > > > > > > > > > > > > method
> > > > > > > > > > > > > > > > > > > > introduced in KIP-1306.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On 2026/06/03 18:31:06 "Matthias J.
> > Sax"
> > > > wrote:
> > > > > > > > > > > > > > > > > > > > > Thanks Andrew.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >  From a KIP-714 perspective, this is
> > a
> > > > great
> > > > > > > > > change,
> > > > > > > > > > > as it
> > > > > > > > > > > > > make
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > new
> > > > > > > > > > > > > > > > > > > > > RPCs and client/broker cross-version
> > > > > > > compatibility
> > > > > > > > > > > clean.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > One question about your
> > `DeleteGroups`
> > > > RPC
> > > > > > > example.
> > > > > > > > > > > Should
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > new
> > > > > > > > > > > > > > > > > > > > > version of the RPC say
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > "clientInstanceIdVersion": "3+",
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > ie, 3+ instead of 3? Similar for
> > other
> > > > request,
> > > > > > > > > which
> > > > > > > > > > > > > don't use
> > > > > > > > > > > > > > > > `+`
> > > > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > > > > > > `clientInstanceIdVersion` field.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > -Matthias
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On 6/2/26 7:42 AM, Andrew Schofield
> > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > > > Following on from the discussion
> > in the
> > > > > > > > > community,
> > > > > > > > > > > and
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > difficulty
> > > > > > > > > > > > > > > > > > > > of trying to accommodate the client
> > > > instance ID
> > > > > > > in a
> > > > > > > > > > > tagged
> > > > > > > > > > > > > field
> > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > > > acceptable complexity, I have made a
> > > > significant
> > > > > > > > > change
> > > > > > > > > > > to
> > > > > > > > > > > > > the KIP.
> > > > > > > > > > > > > > > > > > Now, it
> > > > > > > > > > > > > > > > > > > > introduces v3 of the request header
> > > > containing
> > > > > > > the
> > > > > > > > > client
> > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > ID
> > > > > > > > > > > > > > > > > > as a
> > > > > > > > > > > > > > > > > > > > proper field.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > >
> > https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/KAFKA/KIP-1313*3A*Client*instance*ID*in*all*request*headers__;JSsrKysrKys!!Ayb5sqE7!pUZS25PuTKdhiqvTGcwDKbclqpG8dFOzw2Ax9WxVM6Sb09PVQ0gl1i0gjlr2_Krr66agbuVC2qLGgUcg7vrW$
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Please review and let me know what
> > you
> > > > think.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > > > > > > > > > Andrew
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On 2026/05/28 21:51:01 "Matthias J.
> > > > Sax"
> > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > >> Thanks Andrew. I agree to the
> > issue
> > > > that
> > > > > > > tagged
> > > > > > > > > > > fields
> > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > optional.
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >> Nevertheless, I find the proposed
> > > > > > > compatibility
> > > > > > > > > > > > > protocol too
> > > > > > > > > > > > > > > > > > complex
> > > > > > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > > > > > >> unnecessary, and would still
> > prefer a
> > > > > > > version
> > > > > > > > > bump
> > > > > > > > > > > for
> > > > > > > > > > > > > > > > > > > > > >>
> > > > `GetTelemetrySubscriptionsRequest/Reponse`
> > > > > > > to
> > > > > > > > > clean
> > > > > > > > > > > it
> > > > > > > > > > > > > all
> > > > > > > > > > > > > > > > up. --
> > > > > > > > > > > > > > > > > > For
> > > > > > > > > > > > > > > > > > > > > >> `PushTelemetryRequest` the
> > argument
> > > > from
> > > > > > > above
> > > > > > > > > > > applies,
> > > > > > > > > > > > > so
> > > > > > > > > > > > > > > > > > leaving it
> > > > > > > > > > > > > > > > > > > > > >> untouched is ok.
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >> I don't see why
> > > > > > > > > `GetTelemetrySubscriptionsRequest`
> > > > > > > > > > > > > would need
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > encode
> > > > > > > > > > > > > > > > > > > > > >> the `clientInstandId` in it's
> > request
> > > > body.
> > > > > > > > > Given
> > > > > > > > > > > that
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > >> `clientInstanceId` is a random
> > UUID,
> > > > the
> > > > > > > > > returned
> > > > > > > > > > > > > subscription
> > > > > > > > > > > > > > > > > > cannot
> > > > > > > > > > > > > > > > > > > > > >> really depend on it. So why would
> > we
> > > > need to
> > > > > > > > > send
> > > > > > > > > > > it to
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > broker?
> > > > > > > > > > > > > > > > > > > > > >> Right now, it's set to ZERO only
> > for
> > > > the
> > > > > > > > > purpose to
> > > > > > > > > > > get
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > broker to
> > > > > > > > > > > > > > > > > > > > > >> assign a new UUID. But it has
> > nothing
> > > > to do
> > > > > > > > > with the
> > > > > > > > > > > > > actual
> > > > > > > > > > > > > > > > "what
> > > > > > > > > > > > > > > > > > > > > >> metrics should I send" question.
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >> To be fair, KIP-714 lists
> > > > > > > `client_instance_id`
> > > > > > > > > as a
> > > > > > > > > > > > > field that
> > > > > > > > > > > > > > > > > > can be
> > > > > > > > > > > > > > > > > > > > > >> used to define a subscription.
> > But it
> > > > seems
> > > > > > > > > rather
> > > > > > > > > > > > > useless in
> > > > > > > > > > > > > > > > > > practice
> > > > > > > > > > > > > > > > > > > > > >> to me? I a user defines a
> > > > subscription, they
> > > > > > > > > cannot
> > > > > > > > > > > > > know the
> > > > > > > > > > > > > > > > UUID.
> > > > > > > > > > > > > > > > > > > > Thus,
> > > > > > > > > > > > > > > > > > > > > >> I think we should actually drop
> > > > supporting
> > > > > > > > > > > > > > > > `client_instance_id`
> > > > > > > > > > > > > > > > > > as a
> > > > > > > > > > > > > > > > > > > > > >> "subscription matching
> > parameter"? Of
> > > > > > > course,
> > > > > > > > > there
> > > > > > > > > > > is a
> > > > > > > > > > > > > > > > backward
> > > > > > > > > > > > > > > > > > > > > >> compatibility question, but I
> > think
> > > > we can
> > > > > > > > > address
> > > > > > > > > > > > > this: if
> > > > > > > > > > > > > > > > > > brokers
> > > > > > > > > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > > > > > >> upgraded and they have an existing
> > > > > > > > > > > `client_instance_id`
> > > > > > > > > > > > > based
> > > > > > > > > > > > > > > > > > > > > >> subscription defined, they could
> > > > advertise
> > > > > > > to
> > > > > > > > > only
> > > > > > > > > > > > > support
> > > > > > > > > > > > > > > > v0, and
> > > > > > > > > > > > > > > > > > > > they
> > > > > > > > > > > > > > > > > > > > > >> should log a warning that this
> > > > feature is
> > > > > > > > > > > deprecated.
> > > > > > > > > > > > > New
> > > > > > > > > > > > > > > > brokers
> > > > > > > > > > > > > > > > > > > > would
> > > > > > > > > > > > > > > > > > > > > >> also not allow to use
> > > > `client_instance_id`
> > > > > > > any
> > > > > > > > > > > longer to
> > > > > > > > > > > > > > > > define a
> > > > > > > > > > > > > > > > > > > > > >> subscription.
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >> Similarly, for
> > > > > > > > > `GetTelemetrySubscriptionsResponse`,
> > > > > > > > > > > we
> > > > > > > > > > > > > only
> > > > > > > > > > > > > > > > need
> > > > > > > > > > > > > > > > > > > > > >> `clientInstanceId` if the broker
> > > > computes
> > > > > > > the
> > > > > > > > > UUID.
> > > > > > > > > > > But
> > > > > > > > > > > > > if we
> > > > > > > > > > > > > > > > let
> > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > >> client compute it, this field is
> > not
> > > > needed
> > > > > > > any
> > > > > > > > > > > longer.
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >> -Matthias
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >> On 5/28/26 1:21 AM, Andrew
> > Schofield
> > > > wrote:
> > > > > > > > > > > > > > > > > > > > > >>> Hi Jun,
> > > > > > > > > > > > > > > > > > > > > >>> Thanks for your response.
> > > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > > >>> JR24: I'll update the KIP
> > shortly.
> > > > Here's a
> > > > > > > > > > > summary.
> > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > various
> > > > > > > > > > > > > > > > > > > > modern group protocol heartbeat
> > requests
> > > > encode
> > > > > > > the
> > > > > > > > > > > member
> > > > > > > > > > > > > ID as a
> > > > > > > > > > > > > > > > > > string
> > > > > > > > > > > > > > > > > > > > for historical reasons, even though
> > it's in
> > > > > > > practice
> > > > > > > > > a
> > > > > > > > > > > UUID.
> > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > Apache
> > > > > > > > > > > > > > > > > > > > Kafka Java client happens to use
> > > > > > > > > > > > > org.apache.kafka.common.Uuid to
> > > > > > > > > > > > > > > > > > create the
> > > > > > > > > > > > > > > > > > > > member ID and convert it into a string.
> > > > This
> > > > > > > means
> > > > > > > > > that
> > > > > > > > > > > when
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > clientInstanceId is converted into a
> > > > string, its
> > > > > > > > > encoding
> > > > > > > > > > > > > matches
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > member ID and it all lines up. However,
> > > > there are
> > > > > > > > > other
> > > > > > > > > > > ways
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > encode
> > > > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > > > > UUID into a string and I know for a
> > fact
> > > > that the
> > > > > > > > > > > librdkafka
> > > > > > > > > > > > > client
> > > > > > > > > > > > > > > > > > does it
> > > > > > > > > > > > > > > > > > > > differently.
> > > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > > >>> Thanks,
> > > > > > > > > > > > > > > > > > > > > >>> Andrew
> > > > > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > > > > >>> On 2026/05/27 17:11:25 Jun Rao
> > via
> > > > dev
> > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > >>>> Hi, Andrew,
> > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > >>>> Thanks for the reply. One more
> > > > comment.
> > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > >>>> JR24. "The alignment of other
> > > > identifiers
> > > > > > > is
> > > > > > > > > by
> > > > > > > > > > > > > convention
> > > > > > > > > > > > > > > > (and
> > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > Java
> > > > > > > > > > > > > > > > > > > > > >>>> client will follow the
> > convention)
> > > > rather
> > > > > > > than
> > > > > > > > > > > > > mandate."
> > > > > > > > > > > > > > > > Could
> > > > > > > > > > > > > > > > > > you
> > > > > > > > > > > > > > > > > > > > describe
> > > > > > > > > > > > > > > > > > > > > >>>> the convention to convert a
> > > > > > > clientInstanceId
> > > > > > > > > > > (UUID)
> > > > > > > > > > > > > to a
> > > > > > > > > > > > > > > > > > memberId
> > > > > > > > > > > > > > > > > > > > (String)?
> > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > >>>> Jun
> > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > >>>> On Tue, May 19, 2026 at 2:36 AM
> > > > Andrew
> > > > > > > > > Schofield <
> > > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > >>>>> 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 <
> > > > > > > > > > > > > > > > > > > > schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > >>>>>> 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 <
> > > > > > > > > > > > > > > > > > > > > >>>>>>> schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > >>>>>>>>> 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 <
> > > > > > > > > > > > > > > > > > > > > >>>>>>> schofielaj@apache.org>
> > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> 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
> > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>