[
https://issues.apache.org/jira/browse/KAFKA-20835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18099228#comment-18099228
]
Yunseop Eom commented on KAFKA-20835:
-------------------------------------
Proposed in PR #22935: https://github.com/apache/kafka/pull/22935
- Group-level alter-config validation now checks individual value bounds only
for values changed by the current operation.
- Existing overrides that became out of range after broker bound changes no
longer block unrelated updates.
- Session/heartbeat cross-field validation compares effective values after
clamping stale overrides to current bounds.
- Unknown config names and newly invalid changed values remain rejected.
Verification:
- ./gradlew group-coordinator:test --tests
org.apache.kafka.coordinator.group.GroupConfigTest
- ./gradlew core:test --tests kafka.server.ControllerConfigurationValidatorTest
- ./gradlew core:spotlessCheck group-coordinator:spotlessCheck
All commands passed locally. The PR is open and ready for review.
> Group-level alter-config RPC fails, if single group config is invalid
> ---------------------------------------------------------------------
>
> Key: KAFKA-20835
> URL: https://issues.apache.org/jira/browse/KAFKA-20835
> Project: Kafka
> Issue Type: Bug
> Components: group-coordinator
> Reporter: Matthias J. Sax
> Priority: Minor
>
> ControllerConfigurationValidator gets the full post-alter override map, not
> just the altered keys. So if a broker bound is narrowed after an override was
> set, GroupConfig.validate() rejects the stale value on every later alter –
> even one that doesn't touch it.
> Repro: set consumer.session.timeout.ms=90000 on a group, restart controller
> with group.consumer.max.session.timeout.ms=60000, then try to alter
> consumer.heartbeat.interval.ms on the same group -> INVALID_CONFIG on the
> session timeout.
> Impact: the group is stuck until the stale key is fixed or deleted.
> Validation is all-or-nothing per resource, and throws on the first violation,
> so multiple stale keys must all be repaired in one request, discovered one
> error at a time.
> It seems LogConfig may have a similar issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
