kevin-wu24 commented on code in PR #22505:
URL: https://github.com/apache/kafka/pull/22505#discussion_r3388618378


##########
raft/src/test/java/org/apache/kafka/raft/internals/ChangeVoterHandlerStateTest.java:
##########
@@ -0,0 +1,437 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ *    http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.kafka.raft.internals;
+
+import org.apache.kafka.common.Uuid;
+import org.apache.kafka.common.message.AddRaftVoterResponseData;
+import org.apache.kafka.common.message.RemoveRaftVoterResponseData;
+import org.apache.kafka.common.metrics.KafkaMetric;
+import org.apache.kafka.common.metrics.Metrics;
+import org.apache.kafka.common.protocol.Errors;
+import org.apache.kafka.common.utils.MockTime;
+import org.apache.kafka.raft.Endpoints;
+import org.apache.kafka.raft.ReplicaKey;
+
+import org.junit.jupiter.api.Test;
+
+import java.util.Optional;
+import java.util.concurrent.CompletableFuture;
+
+import static org.junit.jupiter.api.Assertions.assertEquals;
+import static org.junit.jupiter.api.Assertions.assertFalse;
+import static org.junit.jupiter.api.Assertions.assertThrows;
+import static org.junit.jupiter.api.Assertions.assertTrue;
+
+public class ChangeVoterHandlerStateTest {
+
+    private KafkaMetric getMetric(Metrics metrics, String name) {
+        return metrics.metrics().get(metrics.metricName(name, "raft-metrics"));
+    }
+
+    @Test
+    public void testAddVoterLifecycle() {

Review Comment:
   > The thing that stands out to me is why do we have two separate State 
objects to represent a "pending operation," of which the leader can only have 
one.
   
   Currently, it looks like the code doesn't treat updating a voter like how it 
does remove + add voter, but maybe it should (I imagine your follow-up PR with 
the update voter set does change this). 
   
   What I mean by the above is if we have made the decision to only have 
"uncommitted voter change" at a time, why have multiple objects within 
`ChangeVoterHandlerState` to represent this? Having to enforce/verify the "more 
complicated" valid state of the `ChangeVoterHandlerState` (i.e. all internal 3 
add/remove/update must be empty or exactly one must be non-empty are valid 
states) seems odd. It necessitates checking all of these states for things like 
`updateUncommittedVoterChangeMetric()`, and the creation of what seems to be 
duplicate methods like `resetAdd/RemoveVoterHandlerState`, which end up needing 
duplicate unit tests too. Maybe it's okay for the 2-3 states we have now, but 
maybe we will add more in the future. 
   
   What about the `ChangeVoterHandlerState` object having a single internal 
object that is either empty or present? Yes, those state objects would be 
modeled like EpochState.
   
   I guess it comes down to whether or not the current object hierarchy of 
`ChangeVoterHandlerState` having 3 objects or 1 object with 4 possible values 
is easier to read/reason about/maintain. One argument for the current model is 
`ChangeVoterHandlerState` "should" be where the complexity is, going another 
object layer down is kind of "overkill." What do you think? To me, I cannot 
really justify either approach being strictly "better" than the other.



-- 
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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to