Status

Current state: "Under Discussion"Accepted“

Discussion thread: https://lists.apache.org/thread/npdqdmghngwcrh8664gnfmo1zdkjch4k

Vote thread: https://lists.apache.org/thread/glpx2fb2hglbqp1dod6pwjs2f02mnlq1Discussion thread: 

JIRA:  

Motivation

In KAFKA-18225, we identified that ClientQuotaCallback#updateClusterMetadata is not supported in KRaft mode, even though it is supported in Zookeeper mode. In Kafka 4.0, we addressed this gap by implementing the missing functionality; however, some limitations still remain:

...

public interface ClientQuotaCallback extends Configurable {
	...
     /**
     * This callback is invoked whenever there are changes in the cluster metadata, such as 
     * brokers being added or removed, topics being created or deleted, or partition leadership updates.
     * This is useful if quota computation takes partitions into account.
     * Topics that are being deleted will not be included in `cluster`.
     *
	 * @deprecated since 4.24 and should not be used any longer.
     * @param cluster Cluster metadata including partitions and their leaders if known
     * @return true if quotas have changed and metric configs may need to be updated
     */
	@Deprecated(since = "4.24", forRemoval = true)
    default boolean updateClusterMetadata(Cluster cluster);
	 {
       return false;
    }
    ...
}

Documentation

docs/getting-started/upgrade.md

add under Notable changes in 4.4.0

  * The `ClientQuotaCallback#updateClusterMetadata` method is deprecated and will be removed in Kafka 5.0. Custom implementations of `ClientQuotaCallback` no longer need to override this method, as a default no-op implementation is now provided. For further details, please refer to [KIP-1200](https://cwiki.apache.org/confluence/x/axBJFg).

Proposed Changes

Deprecating ClientQuotaCallback#updateClusterMetadata. No alternative method will be introduced, as there is currently no known demand for this functionalitybecause the method showed no demand during its three-year absence before 4.0, and its reintroduced form contains multiple pitfalls that would require significant effort to fix.

Compatibility, Deprecation, and Migration Plan

...

• While KIP-1162 proposes a redesign, we’re letting updateClusterMetadata take a nap for now—but if a real use case shows up, we’re ready to wake it up and bring it back!, this approach adds considerable engineering cost and complexity, yet brings little practical benefit, as the method has seen almost no demand and the existing implementation already exposes multiple pitfalls.