Hi Jun, > So, the new controller > should be able to send a version of the AddRaftVoter request that the > leader supports, right?
The new controller can send a supported version for the RPC, but we do not want that to happen. This is because a controller sending AddRaftVoter with version 0 can cause the unavailability scenario described in the Motivation section. By making the field not ignorable, the local NetworkClient will return an unsupported version response without actually sending anything over the wire. Best, Kevin Wu On Tue, Jun 17, 2025 at 9:40 AM Kevin Wu <kevin.wu2...@gmail.com> wrote: > Hi Alyssa, > > Thanks for the feedback. > 1. Yeah, I guess I do not state explicitly why this issue does not impact > controllers that are manually added via the AdminClient. I'll add a section > to clarify the difference in the situations. > 2. I touched on this a bit in the Proposed Changes section, but I agree > with José on the documentation of this field. How the field is set is up to > the implementation, which can change over time (what if the AdminClient > changes in the future to return a response before commitment?), so > documenting how we're using it now is not as accurate as documenting what > changes in the KRaft protocol. > > Best, > Kevin Wu > > On Thu, Jun 12, 2025 at 11:49 AM Kevin Wu <kevin.wu2...@gmail.com> wrote: > >> Hi Jose, >> >> Thanks for the feedback. I agree with the solution of not ignoring the >> new field, and I see how the current documentation is not descriptive in >> terms of what the flag is actually doing within the protocol. I will update >> the KIP to change these things. >> >> Best, >> Kevin >> >> On Wed, Jun 11, 2025 at 2:55 PM Kevin Wu <kevin.wu2...@gmail.com> wrote: >> >>> Hello all, >>> >>> I wrote a KIP to add a new boolean field to the AddRaftVoterRequest RPC. >>> Here is the link: >>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1186%3A+Update+AddRaftVoterRequest+RPC+to+support+auto-join >>> >>> >>> Thanks, >>> Kevin Wu >>> >>
