[GitHub] [kafka] lbradstreet commented on a change in pull request #8609: KAFKA-9946; StopReplicaRequest deletePartition changes may cause premature topic deletion handling in controller

[GitBox <gi...@apache.org>]

lbradstreet commented on a change in pull request #8609:
URL: https://github.com/apache/kafka/pull/8609#discussion_r419725599



##########
File path: core/src/main/scala/kafka/controller/ControllerChannelManager.scala
##########
@@ -590,7 +569,26 @@ abstract class AbstractControllerBrokerRequestBatch(config: KafkaConfig,
 
           stateChangeLog.info(s"Sending StopReplica request for ${partitionStates.size} " +
             s"replicas to broker $brokerId")
-          sendStopReplicaRequest(brokerId, brokerEpoch, false, stopReplicaTopicState)
+          val stopReplicaRequestBuilder = new StopReplicaRequest.Builder(
+            stopReplicaRequestVersion, controllerId, controllerEpoch, brokerEpoch,
+            false, stopReplicaTopicState.values.toBuffer.asJava)
+
+          sendRequest(brokerId, stopReplicaRequestBuilder, (r: AbstractResponse) => {
+            val stopReplicaResponse = r.asInstanceOf[StopReplicaResponse]

Review comment:
       It seems like we could keep the response callback creation method in the previous PR if we passed in partitionStates to the callback builder, or alternately create a map of the partitions that you expect to be deleted. I think this would save the code duplication in creating nearly the same callback which I believe is being done to deal with the differences in the deletePartition schemas i.e. all partitions in request vs specific partitions.




----------------------------------------------------------------
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:
users@infra.apache.org