Hi Jun, Thanks for the feedback. See my comments below.
On Tue, Feb 27, 2024 at 11:27 AM Jun Rao <j...@confluent.io.invalid> wrote: > 30. Who controls RPCs like Fetch, FetchSnapshot, DescribeQuorum RPC? They > are shared between voters and observers. For Fetch and FetchSnapshot, this KIP adds the tagged field ReplicaUuid to the request. This means that if the sender supports the latest version it can always add the replica uuid to the request. If the receiver supports the new tagged field it is included in the appropriate FetchRequestData and FetchSnapshotRequestData field. If it doesn't support the new tagged field it will be in the unknown tagged fields. For DescribeQuorum, this KIP only changes the response. The KRaft leader will inspect the RequestHeader::apiVersion to determine what information to include in the response. > Does the client use supported ApiKeys or kraft.version feature in > ApiVersions response for deciding whether to send AddVoter requests? That's a good point. The Admin client has access to the finalized kraft.version in the ApiVersions response. I was thinking of only using the ApiKeys since we don't have a precedence of using the finalized features in the Admin client. The receiver of the request still needs to validate the kraft.version for those requests and return an UNSUPPORTED_VERSION error in those cases. Do you mind if we define this in a separate KIP? Thanks, -- -José
