hachikuji opened a new pull request, #12150:
URL: https://github.com/apache/kafka/pull/12150

   When a partition leader receives a `Fetch` request from a replica which is 
not in the current replica set, the behavior today is to return a successful 
fetch response, but with empty data. This causes the follower to retry until 
metadata converges without updating any state on the leader side. It is clearer 
in this case to return an error, so that the metadata inconsistency is visible 
in logging and so that the follower backs off before retrying. 
   
   The question then is what error to return? In this patch, we use 
`UNKNOWN_LEADER_EPOCH` when the `Fetch` request includes the current leader 
epoch. The way I see this is that the leader is validating the (replicaId, 
leaderEpoch) tuple. When the leader returns `UNKNOWN_LEADER_EPOCH`, it means 
that the leader does not expect the given leaderEpoch from that replica. If the 
request does not include a leader epoch, then we use `NOT_LEADER_OR_FOLLOWER`. 
We can squint our eyes a little and take a similar interpretation for this 
case: the leader is rejecting the request because it does not think it should 
be the leader for that replica. But mainly these errors ensure that the 
follower will retry the request.
   
   As a part of this patch, I have refactored the way that the leader updates 
follower fetch state. Previously, the process is slightly convoluted. We send 
the fetch from `ReplicaManager` down to `Partition.readRecords`, then we 
iterate over the results and call `Partition.updateFollowerFetchState`. It is 
more straightforward to update state directly as a part of `readRecords`. All 
we need to do is pass through the `FetchParams`. This also prevents an 
unnecessary copy of the read results.
   
   
   
   ### Committer Checklist (excluded from commit message)
   - [ ] Verify design and implementation 
   - [ ] Verify test coverage and CI build status
   - [ ] Verify documentation (including upgrade notes)
   


-- 
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]

Reply via email to