chia7712 commented on code in PR #20334:
URL: https://github.com/apache/kafka/pull/20334#discussion_r2511578779
##########
docs/upgrade.html:
##########
@@ -113,6 +113,35 @@ <h5><a id="upgrade_420_notable"
href="#upgrade_420_notable">Notable changes in 4
<li>
The <code>num.replica.fetchers</code> config has a new lower bound of
1.
</li>
+ <li>
+ Improvements have been made to the validation rules and default values
of LIST-type configurations
+ (<a href="https://cwiki.apache.org/confluence/x/HArXF";>KIP-1161</a>).
+ <ul>
+ <li>
+ LIST-type configurations now enforce stricter validation:
+ <ul>
+ <li>Null values are no longer accepted for most LIST-type
configurations, except those that explicitly
+ allow a null default value or where a null value has a
well-defined semantic meaning.</li>
+ <li>Duplicate entries within the same list are no longer
permitted.</li>
Review Comment:
I ran a small test where a cluster was created with a custom cluster-wide
config, and then a node with an "increased" lower bound was added. The
resulting error is shown below
```
[2025-11-10 18:24:32,358] ERROR Cluster default configs could not be
applied: java.util.Collections$3@eec0c96 (kafka.server.DynamicBrokerConfig)
org.apache.kafka.common.config.ConfigException: Invalid value 1048576 for
configuration segment.bytes: Value must be at least 2097152
at
org.apache.kafka.common.config.ConfigDef$Range.ensureValid(ConfigDef.java:989)
at
org.apache.kafka.common.config.ConfigDef.parseValue(ConfigDef.java:540)
at org.apache.kafka.common.config.ConfigDef.parse(ConfigDef.java:524)
at
org.apache.kafka.common.config.AbstractConfig.<init>(AbstractConfig.java:118)
at
org.apache.kafka.common.config.AbstractConfig.<init>(AbstractConfig.java:149)
at
org.apache.kafka.storage.internals.log.LogConfig.<init>(LogConfig.java:299)
at
org.apache.kafka.storage.internals.log.LogConfig.<init>(LogConfig.java:294)
at
kafka.server.DynamicLogConfig.reconfigure(DynamicBrokerConfig.scala:716)
at
kafka.server.DynamicBrokerConfig.$anonfun$updateCurrentConfig$1(DynamicBrokerConfig.scala:546)
at
kafka.server.DynamicBrokerConfig.$anonfun$updateCurrentConfig$1$adapted(DynamicBrokerConfig.scala:546)
at scala.collection.immutable.List.foreach(List.scala:323)
at
kafka.server.DynamicBrokerConfig.updateCurrentConfig(DynamicBrokerConfig.scala:546)
at
kafka.server.DynamicBrokerConfig.$anonfun$updateDefaultConfig$1(DynamicBrokerConfig.scala:397)
at
kafka.server.DynamicBrokerConfig.updateDefaultConfig(DynamicBrokerConfig.scala:393)
at
kafka.server.BrokerConfigHandler.processConfigChanges(ConfigHandler.scala:150)
at
kafka.server.metadata.DynamicConfigPublisher.$anonfun$onMetadataUpdate$5(DynamicConfigPublisher.scala:81)
at scala.Option.foreach(Option.scala:437)
at
kafka.server.metadata.DynamicConfigPublisher.$anonfun$onMetadataUpdate$2(DynamicConfigPublisher.scala:74)
at java.base/java.util.HashMap$KeySet.forEach(HashMap.java:1017)
at
kafka.server.metadata.DynamicConfigPublisher.$anonfun$onMetadataUpdate$1(DynamicConfigPublisher.scala:57)
at
kafka.server.metadata.DynamicConfigPublisher.$anonfun$onMetadataUpdate$1$adapted(DynamicConfigPublisher.scala:56)
at scala.Option.foreach(Option.scala:437)
at
kafka.server.metadata.DynamicConfigPublisher.onMetadataUpdate(DynamicConfigPublisher.scala:56)
at
kafka.server.metadata.BrokerMetadataPublisher.onMetadataUpdate(BrokerMetadataPublisher.scala:218)
at
org.apache.kafka.image.loader.MetadataLoader.initializeNewPublishers(MetadataLoader.java:315)
at
org.apache.kafka.image.loader.MetadataLoader.lambda$scheduleInitializeNewPublishers$0(MetadataLoader.java:272)
at
org.apache.kafka.queue.KafkaEventQueue$EventContext.run(KafkaEventQueue.java:134)
at
org.apache.kafka.queue.KafkaEventQueue$EventHandler.handleEvents(KafkaEventQueue.java:217)
at
org.apache.kafka.queue.KafkaEventQueue$EventHandler.run(KafkaEventQueue.java:188)
```
> Silently increase the value used to the new lower bound, I would say.
This appears to be a viable solution, but we first need to reach a consensus
on the compatibility rule for configuration breaking changes in a major
release.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
