You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Christo Lolov (Jira)" <ji...@apache.org> on 2025/12/19 11:54:00 UTC

[jira] [Commented] (KAFKA-19851) Delete dynamic config that were removed by Kafka

    [ https://issues.apache.org/jira/browse/KAFKA-19851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18046575#comment-18046575 ] 

Christo Lolov commented on KAFKA-19851:
---------------------------------------

Heya, this isn't marked as a blocker for 4.2 and we are past the code freeze date! What is the state of implementation, is it a blocker, is it nearly done or should I be moving it to the 4.3 release :) ?

> Delete dynamic config that were removed by Kafka
> ------------------------------------------------
>
>                 Key: KAFKA-19851
>                 URL: https://issues.apache.org/jira/browse/KAFKA-19851
>             Project: Kafka
>          Issue Type: Improvement
>          Components: controller
>    Affects Versions: 4.0.1, 4.1.0
>            Reporter: José Armando García Sancio
>            Assignee: tony tang
>            Priority: Major
>             Fix For: 4.2.0, 4.0.2
>
>
> [KIP-724: Drop support for message formats v0 and v1|https://cwiki.apache.org/confluence/display/KAFKA/KIP-724%3A+Drop+support+for+message+formats+v0+and+v1]  and Kafka 4.0.0 removed support for the dynamic configs like message.format.version.
> When the user upgrades from 3.x to 4.x it can cause the dynamic configuration validation to fail if there are dynamic configurations that are no longer supported.
> {code:java}
> Caused by: org.apache.kafka.common.errors.InvalidConfigurationException: Unknown topic config name: message.format.version {code}
> One solution for solving this problem is to have a well define list of allowed dynamic configuration. Any config that doesn't match this list will be automatically deleted.
> This deletion can be done implicitly when applying the ConfigRecord record. This behavior can be further guarded by checking that the metadata version is greater than 4.0. This also means that upgrading the metadata version to 4.0 would cause all of the removed config to get deleted.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)