C0urante commented on PR #13453: URL: https://github.com/apache/kafka/pull/13453#issuecomment-1501923378
@vamossagar12 I think this approach is a bit too broad. We intentionally permit "unsafe" writes for reasons documented in the [AbstractHerder](https://github.com/apache/kafka/blob/17435484e4c49eef440ee412a711a88fed08bf50/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/AbstractHerder.java#L90-L109) and [KafkaStatusBackingStore](https://github.com/apache/kafka/blob/17435484e4c49eef440ee412a711a88fed08bf50/connect/runtime/src/main/java/org/apache/kafka/connect/storage/KafkaStatusBackingStore.java#L74-L87) Javadocs. Specifically: > this prevents us from depending on the generation absolutely. If the group disappears and the generation is reset, then we'll overwrite the status information with the older (and larger) generation with the updated one. The danger of this approach is that slow starting tasks may cause the status to be overwritten after a rebalance has completed. I have a few alternatives in mind for how we might address this, but haven't fully thought any of them through yet since there are several KIP PRs that need to be reviewed right now which I'm giving priority to. To give me some idea of how highly to prioritize this once those are taken care of, can you let me know if this issue is actively affecting you or someone you know, or if the PR is a way to get up-to-speed with Kafka Connect, or something else? -- 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: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
