...

• User familiarity:  Most users and applications connect using  bootstrap.servers and are already accustomed to the broker's behavior. 
• Stricter validation logic: The broker enforces stricter validation rules. This stricter validation helps catch errors early and prevents ambiguous configuration states. Moving from strict to lenient would introduce correctness and safety risks, whereas the current inconsistency is a bug that should be fixed.
• Clearer error semantics: The broker uses the INVALID_REQUEST error code, which accurately reflects the situation. The controller's use of UNSUPPORTED_VERSION is misleading since this is not a version compatibility issue.

Beyond the behavioral inconsistencies described above, there is a fundamental architectural reason why broker configuration validation must be performed with access to the target broker's local context:

Broker configuration validation requires access to local broker context that may not be available when processing requests remotely. so when a controller receives a request to modify broker configurations for a different node, it cannot access that remote broker's local resources and therefore cannot perform complete validation. If the controller were to accept and apply broker configurations for other nodes without proper validation, it could lead to:

• Invalid configurations being silently applied, causing broker startup failures or runtime errors
• Security misconfigurations when SSL/SASL settings are not properly validated

Therefore, we should ensure that:

• Broker configuration requests for remote brokers are rejected by the controller with clear error messages directing users to the appropriate endpoint

Before this KIP, we will gain the following benefits from Benefits of alignment:

• We can unify the processing logic and reduce code complexity
• Users will have a better experience when using the Admin API
• Reduced confusion for both users and Kafka developers

Public Interfaces

This KIP introduces the following behavioral changes: does not change any public interfaces.

Proposed Changes

We align the controller behavior with the broker behavior by extracting common validation logic and applying it to both code paths. The following describes how each inconsistency is addressed:

Null value handling

• Validate that null values are allowed only with the AlterConfigOp.OpType.DELETE operation.

• Throw an InvalidRequestException if null values are used with other operation types (e.g., SET).

• Apply this validation to both the broker and controller paths before request processing.

Duplicate configuration handling

• Detect duplicate config keys within a single request and immediately throw an InvalidRequestException.

• This prevents later values from silently overwriting earlier values on the controller path.

Unknown resource type error codes

• Validate that the resource type is not UNKNOWN before processing the request.

• The controller returns INVALID_REQUEST instead of UNSUPPORTED_VERSION for unknown resource types.

Invalid dynamic configs

• Validate configuration values on the controller before applying them.

• Throw an InvalidRequestException immediately when validation fails, preventing silent drops of invalid configs

...

Controller request filtering

...

• .

The validation logic is extracted into a shared utility that is reused by both KafkaApis (broker path) and ControllerApis (controller path), ensuring consistent and deterministic behavior across both code paths.

Compatibility, Deprecation, and Migration Plan

...