jsancio commented on code in PR #22505:
URL: https://github.com/apache/kafka/pull/22505#discussion_r3437394890
##########
raft/src/main/java/org/apache/kafka/raft/UnattachedState.java:
##########
@@ -87,6 +87,11 @@ public int epoch() {
return epoch;
}
+ @Override
+ public LeaderAndEpoch leaderAndEpoch() {
+ return new LeaderAndEpoch(leaderId, epoch);
Review Comment:
It could be empty but not necessarily. Because of KIP-853, a follower may
know the leader id but not the leader's endpoints. When we implemented KIP-853,
I updated the Java Doc for this state. It now reads:
```java
/**
* A replica is "unattached" when it doesn't know the leader or the
leader's endpoint.
*
* Typically, a replica doesn't know the leader if the KRaft topic is
undergoing an election cycle.
*
* It is also possible for a replica to be unattached if it doesn't know
the leader's endpoint.
* This typically happens when a replica starts up and the known leader id
is not part of the local
* voter set. In that case, during startup the replica transitions to
unattached instead of
* transitioning to follower. The unattached replica discovers the leader
and leader's endpoint
* either through random Fetch requests to the bootstrap servers or
through BeginQuorumEpoch
* request from the leader.
*/
```
I used Unattached for this state instead of Follower state. To me the key
invariants are that Followers fetch from the leader and unattached fetch from
the bootstrap servers.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
