rondagostino edited a comment on pull request #10155: URL: https://github.com/apache/kafka/pull/10155#issuecomment-781610292
@cmccabe When we defer partition changes we batch everything up and only apply the latest changes at the end. I'm pretty sure you weren't asking about that, but I wanted to make it explicit just to be certain. So there is no chance of becoming a leader for a deferred partition after becoming a follower for it -- we only apply the end state, and that is either leader or follower. What I think you were asking about is what happens if sometime later we transition to leader. That would be taken care of by the normal partition metadata processing logic. The partition remains "Online" during this entire transition. A partition transitions to Offline only when there is a log dir failure (as an aside, that is not yet implemented for Raft-based clusters). In the absence of a log dir failure a partition can only transition between Online, Deferred, and None (with None signifying we are not a leader or a follower). Deferred only occurs at startup and if the broker becomes fenced after startup (this latter case is also not yet implemented). So we transition only between Online and None, and again the normal partition metadata processing logic handles these. That logic will also handle other transitions to/from Deferred and into Offline once we implement those. So I believe there is no problem here. ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected]
