Also, in the response schema, I think the last line is a bit misleading. As we discussed offline, the field can be either Recovering or Recovered, depending on when the leader sent out an AlterPartition request to the controller (i.e. during recovery or after recovery has completed). But the broker does not take the value in this field as a trigger to start recovery. That happens through either the LeaderAndIsr request or the relevant change record in Kraft world. ``` Response Schema The name of the request will be changed to AlterPartitionResponse from AlterIsrResponse. The field CurrentIsrVersion will be renamed to PartitionEpoch. Add a property to indicate to the leader of the topic partition that it is must recover the partition. ```
On Fri, Feb 4, 2022 at 11:55 AM José Armando García Sancio <jsan...@confluent.io.invalid> wrote: > > David Jacot wrote: > > > The behavior of the leader is clear. However, the part which is > > not clear to me is how followers which could get fetch requests > > from consumers as well will handle them. Sorry if I was not clear. > > Got it. I updated the KIP to add more information regarding how the > topic partition follower will handle LEADER_AND_ISR request. In other > words, the follower will return a NOT_LEADER_OR_FOLLOWER error if the > leader is RECOVERING from an unclean leader election. > > Thanks, > -- > -José -- Best Regards, Raman Verma
