...

• UNKNOWN_TOPIC_OR_PARTITION (3) If the topic or partition doesn't exist on any broker in the cluster. Note that the use of this code is not precisely the same as it's usual meaning of "This server does not host this topic-partition".

•  NOT_CONTROLLER (41) If the request is sent to a broker that is not the controller for the cluster.

• REPLICA_LEADER_ELECTION_IN_PROGRESS (new) if elections are already in progress. The request can be retried at a later time.
• TOPIC_AUTHORIZATION_FAILED (29) If the user didn't have Alter access to the topic.
• NONE (0) The election has successfully been started.

Broker-side election algorithm

The broker-side handling of ElectPreferredReplicaLeaderRequest will be somewhat different than currently:

1. On receipt of ElectPreferredReplicaLeaderRequest the controller will atomically check-and-set a flag (to prevent concurrent elections) then enqueue a PreferredReplicaLeaderElection with the ControllerManager
2. The controller will when await completion of the PreferredReplicaLeaderElection, with a timeout.
3. When processing the PreferredReplicaLeaderElection the controller will clear the flag.
4. Successful or timed-out completion of the PreferredReplicaLeaderElection will result in a ElectPreferredReplicaLeaderResponse being returned to the client

(The flag will also be checked-and-set when handling a change of the /admin/preferred_replica_election znode, via the existing --zookeeper-supporting code)

This change means that the ElectPreferredReplicaLeaderResponse is sent when the election is actually complete, rather than when the /admin/preferred_replica_election znode has merely been updated. Thus if the election fails, the ElectPreferredReplicaLeaderResponse's error_code will provide a reason.

When support for the --zookeeper option is eventually removed, the need for the /admin/preferred_replica_election znode will disappear and consequently the code managing it will be removed.

Compatibility, Deprecation, and Migration Plan

...