At the detailed level: Let's consider topics that are enqueued for deletion but haven't started the actual deletion, maybe they have ongoing partition reassignments that would still take many hours to finish. And for those partitions during a controlled shutdown we won't try to switch leaderships because we no longer care about their availability. And here even if the shutting down broker is still leader for those partitions, I think it's ok to shutdown the broker immediately because again we don't care about the partition availability anymore. Using !isTopicWithDeletionStarted will still return those partitions and block the controlled shutdown, which is probably not ideal.
At a higher level: isTopicQueuedUpForDeletion is used in many other places so that for other types of operations, once a topic is enqueued, it effectively no longer exists. I think that also applies here, and using the same method consistently simplifies reasoning. Thoughts? [ Full content available at: https://github.com/apache/kafka/pull/5388 ] This message was relayed via gitbox.apache.org for [email protected]
