Hi Michael, > No alternative method will be introduced, as there is currently no known demand > for this functionality.
Perhaps “no demand” was too strong a wording — apologies for that. The real issue is that in 4.0 we reintroduced ClientQuotaCallback#updateClusterMetadata(Cluster cluster) for KRaft (it wasn’t available before then), but we didn’t handle it carefully. This method comes with a number of potential pitfalls — especially the one described in KAFKA-19122 <https://issues.apache.org/jira/browse/KAFKA-19122> . That’s why I initially proposed KIP-1162, which tries to redesign the method. But that proposal introduced quite a few changes, and the discussion didn’t generate much feedback. Given that updateClusterMetadata is error-prone, fixing it properly would require significant engineering effort, and, as far as we can tell, it’s “almost” unused. This method wasn’t implemented for over three years (since KRaft was introduced), no users have reported issues during that time, and it was only reintroduced in 4.0 about half a year ago. That’s why KIP-1200 proposes removing it altogether rather than redesigning it. See https://lists.apache.org/thread/otc7d6z19h5d86o17qr72g23wkxffkvo. I realize having two KIPs around the same method can be confusing. My goal here is simply to address the underlying risk and find the most practical resolution. Since we’re now voting on KIP-1200, I consider KIP-1162 dropped, and I’ll make sure to clarify this in the KIP-1200. Apologies for the confusion. As for this point: > I'm aware of multiple ClientQuotaCallback implementations that rely on that method. >From what I see in the Kafka trunk codebase, the only reference is in DynamicTopicClusterQuotaPublisher#onMetadataUpdate. Am I overlooking other usage? Best, Kuan-Po Tseng On Sat, Sep 13, 2025 at 12:04 AM Mickael Maison <mickael.mai...@gmail.com> wrote: > Hi, > > We have KIP-1162 to rethink ClientQuotaCallback. I think it would make > sense to handle the deprecation of older APIs in that KIP. > I'm not sure I understand why we have a separate KIP (this KIP). > > The KIP states "No alternative method will be introduced, as there is > currently no known demand for this functionality.". > How did you come to that conclusion? I'm aware of multiple > ClientQuotaCallback implementations that rely on that method. > Otherwise why would you also open KIP-1162, these 2 KIPs contradict > each other! > > I don't want to vote for a feature to be deprecated and eventually > removed without a clear plan for its users. > > Thanks, > Mickael > > On Fri, Sep 12, 2025 at 2:03 AM Chia-Ping Tsai <chia7...@apache.org> > wrote: > > > > hi kuan-po > > > > the KIP looks good to me. Do you plan to start the vote thread? > > > > Best, > > Chia-Ping > > > > On 2025/07/30 16:17:46 Kuan-Po Tseng wrote: > > > Hi folks, > > > > > > I'd like to start a discussion thread about deprecating > > > ClientQuotaCallback#updateClusterMetadata. > > > > > > For more context and details, please refer to the KIP: > > > https://cwiki.apache.org/confluence/x/axBJFg > > > > > > Thanks! > > > > > > Best regards, > > > Kuan-Po Tseng > > > >
