...

--- a/clients/src/main/resources/common/message/AddRaftVoterRequest.json
+++ b/clients/src/main/resources/common/message/AddRaftVoterRequest.json
@@ -18,7 +18,8 @@
   "type": "request",
   "listeners": ["controller", "broker"],
   "name": "AddRaftVoterRequest",
-  "validVersions": "0",
+  // Version 1 adds the fromControllerAckWhenCommitted field.
+  "validVersions": "0-1",
   "flexibleVersions": "0+",
   "fields": [
     { "name": "ClusterId", "type": "string", "versions": "0+", "nullableVersions": "0+",
@@ -37,6 +38,8 @@
         "about": "The hostname." },
       { "name": "Port", "type": "uint16", "versions": "0+",
         "about": "The port." }
-    ]}
+    ]},
+    { "name": "FromControllerAckWhenCommitted", "type": "bool", "versions": "1+", "ignorabledefault": "true",
+      "about": "TrueWhen iftrue, thereturn requesta isresponse sentafter fromthe anothernew controllervoter asset partis ofcommitted. controllerOtherwise, autoreturn joining,after falsethe ifleader sent viawrites the adminchanges clientlocally." }
   ]
 }

Compatibility, Deprecation, and Migration Plan

The main compatibility case to handle is a follower sending this request with version 1 to a leader which only supports version 0.

The follower should not send the AddRaftVoter request if the leader doesn't support the version, because we do not want to cause the unavailability scenario described above. Therefore, the new field should not be ignored and the sending replica should handle the unsupported version exception and error. We used a similar mechanism when designing and implementing the KIP-996: Pre-Vote.

This means that both the leader and the follower need to support version 1 of AddRaftVoter for the auto-join feature to work. The advantage of this solution is that it doesn't cause any unavailability in the KRaft partition (the cluster metadata partition)To make this change backwards compatible, we can make this field ignorable. This ensures compatibility between a controller that is adding itself with the new AddRaftVoterRequest via auto-join, and an old active controller that does not understand this field (i.e. does not have the auto-join feature). In that case, the unavailability issue described above is possible.

Test Plan

Add a unit test to test for compatibility.

...

• Kafka doesn't support multiple in-flight requests on the "server" side. What this means exactly is that the receiver of a request mutes the connection of the socket it reads from, making it unable to process another in-flight request on that connection until it sends a response back for the first.
  • Adding support for this has much larger implications outside of KRaft and would require another KIP.
• Because of the point above, this means KRaft would need to establish 2 connections. One for AddRaftVoterRequest and one for essentially everything else. We found this solution to be overkill for our auto-join, and felt that hardcoding two connections is bad design.

For compatibility:
To make this change backwards compatible, we can make this field ignorable. This ensures compatibility between a controller that is adding itself with the new AddRaftVoterRequest via auto-join, and an old active controller that does not understand this field (i.e. does not have the auto-join feature). In that case, the unavailability issue described above is possible.