Long-standing bugs often become features.

Let's keep this behavior for 3.9.2. I recommend updating the documentation
to explicitly highlight this distinction.


Ismael Juma <[email protected]> 於 2025年12月4日週四 上午6:23寫道:

> Thanks for starting the discussion. Given that this behavior has existed
> for so long, I would be reluctant to change it in a patch release for 3.9.x
> unless there is strong demand from the community.
>
> Ismael
>
> On Mon, Dec 1, 2025 at 6:18 AM PoAn Yang <[email protected]> wrote:
>
> > Hi developers,
> >
> > I'd like to initiate a discussion regarding the AlterConfigPolicy in
> > version 3.9.2.
> > https://issues.apache.org/jira/browse/KAFKA-19026
> >
> > The key issue is the difference in behavior for OpType.SUBTRACT and
> > OpType.APPEND between KRaft and ZK modes.
> >
> > In KRaft mode, AlterConfigPolicy#validate receives the modified
> > RequestMetadata.
> > In ZK mode, it receives the original user input.
> >
> > We can observe this difference by looking at the OpType.SUBTRACT example
> > provided in the attachments:
> >
> >
> https://issues.apache.org/jira/secure/attachment/13075589/KAFKA19026Test.java
> >
> >
> https://issues.apache.org/jira/secure/attachment/13075585/KAFKA19026Policy.java
> >
> > Example Output in KRaft Mode:
> > AlterConfigPolicy.RequestMetadata(resource=ConfigResource(type=BROKER,
> > name='0'), configs={ssl.cipher.suites=}).
> >
> > Example Output in ZK Mode:
> > AlterConfigPolicy.RequestMetadata(resource=ConfigResource(type=BROKER,
> > name='0'), configs={ssl.cipher.suites=foo}).
> >
> > The ZK behavior has been in place since 2.3.1. Therefore, I want to check
> > if the community wants to align this behavior in 3.9.2.
> >
> >
> >
> https://github.com/apache/kafka/blob/2.3.1/core/src/main/scala/kafka/server/AdminManager.scala#L462-L479
> >
> > If this is considered a behavioral change, it might be risky to include
> in
> > a patch version (3.9.2). However, if it's classified as a bug, then we
> > should proceed with the fix in 3.9.2.
> >
> > Feel free to share your opinions. Thank you!
> >
> > Best regards,
> > PoAn
>

Reply via email to