Page History

...

No efforts will be made to verify the actual contents of the logs for any workers. KIP-495 was  was published several years ago and has proven to be effective; since we anticipate that the logic for reading/writing log levels will be largely preserved, it should be enough to rely on the API for querying the Kafka Connect-reported levels of logging namespaces.

...

This proposal introduces a second kind of record to the config topic that's used for cluster-wide communication, but that is meant to be ignored by any workers brought up after it has been written (the first being the one added in KIP-745). These kinds of records runs the risk of flooding the config topic with many records that, due to the compacted nature of the topic, will never be discarded, leading to a monotonically-growing topic.

...

However, we may still want to invest some time in cleanup logic for the config topic, where "control records" like the ones proposed here and introduced in KIP-745 are  are followed up with corresponding tombstone records after enough time has elapsed, so that when compaction takes place, they are effectively removed from the topic.