I'm still having trouble understanding how the configs could match in the code
you highlighted when we change connector and/or task config values when no keys
are being pruned by the connector implementations in question.Would capturing a
new generation value within the config itself on every submitted change be a
possible fix/workaround?The possible slightly negative consequence of that
change would be that re-submitting the same config which would effectively be a
no-op in the current implementation would now force task reconfigures/restarts?
On Wednesday, February 8, 2023, 12:47:19 PM EST, Greg Harris
<greg.har...@aiven.io.invalid> wrote:
> This is the condition which is causing the issue:
> https://github.com/apache/kafka/blob/6e2b86597d9cd7c8b2019cffb895522deb63c93a/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/distributed/DistributedHerder.java#L1918-L1931>
> The DistributedHerder is comparing the generation 1 and generation 2
> configurations, and erroneously believes that they are equal, when in fact
> the underlying secrets have changed.> This prevents the DistributedHerder
> from writing generation 2 task configs to the KafkaConfigBackingStore
> entirely, leaving it in state (A) without realizing it.
