Hi David, Thanks for the KIP.
> ReplicaStateEventResponse => ErrorCode [Topic [PartitionId]] > ErrorCode => Int32 > Topic => String > PartitionId => Int32 > ... > Partition-level errors: Based on my understanding of the response, it doesn't look like the controller has a way of encoding these partition-level errors. > INVALID_REQUEST: The update was rejected due to some internal inconsistency > (e.g. invalid replicas specified in the ISR) What do you mean by "invalid replicas specified in the ISR"? There is no reference to ISR in the request. Related to this, can you mention how the broker/replica will handle the errors included in the ReplicaStatusEventResponse? > In this proposal, we now include the broker ID and epoch in the request, so > the controller can safely update its internal replica state based on the > request data. > ... > If the controller reads the ReplicaStateEvent and encounters a fatal error > before handling the subsequent ControllerEvent, a new controller will > eventually be elected and the state of all replicas will become known to the > new controller. I think we should mention that the controller will keep it's current implementation of marking the replicas as offline because of failure in the LeaderAndIsr response. -- -Jose
