...

• FENCED_LEADER_EPOCH: There is a new leader for the topic partition. The leader should not retry.
• INVALID_REQUEST: The update was rejected due to some internal inconsistency (e.g. invalid replicas specified in the ISR)
• INVALID_ISR_VERSION (NEW): The (Zk)version in the request is out of date. Likely there is a pending LeaderAndIsr request which the leader has not yet received.
• UNKNOWN_TOPIC_OR_PARTITION: The topic no longer exists.

Proposed Changes

In The main change in this KIP , we propose to let AlterIsr requests be sent to the controller and handled asynchronously without blocking the leader. The basic idea is to always assume the most conservative current ISR when advancing the high watermark given a pending update.

ISR Shrink: we require successful acknowledgement from the controller before a follower can be taken out of the ISR and the high watermark advanced. The leader will send the AlterIsrRequest, but will keep the current ISR fixed until a successful response is received.

ISR Expand: followers are added to the local ISR immediately without waiting for acknowledgement from the controller. Even if the ISR expansion fails, the exposed high watermark will be less than or equal to the "true" valueis to send the AlterIsr request to the controller when shrinking or expanding the ISR on the leader. Today we get some performance benefit from batching leader and ISR updates to the controller by delaying propagation. This allows the controller to batch metadata updates to the cluster. We can get the same benefit with this KIP. The AlterIsr request will be routed through the controller and Zookeeper will be updated synchronously. The controller can then choose to delay propagation of the metadata updates in order to batch them.

Compatibility, Deprecation, and Migration Plan

...