-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OffsetFetchResponse
and OffsetCommitRequest
leaderEpoch
is not working as expected
#2694
Labels
Comments
Thanks this is a good catch! Will work on a fix |
dnwe
added a commit
that referenced
this issue
Nov 2, 2023
The `fetchInitialOffset` func in offsetManager was hardcoded to send a Version 1 OffsetFetchRequest rather than sending the appropriate version based on the config KafkaVersion. As discussed in #2694 this meant that LeaderEpoch was always being decoded as the default value '0' (because it was only returned in Version >= 5 OffsetFetchRequest). However, other areas of the offsetManager code were sending the newer protocol versions, so for example the OffsetCommitRequest would include a leader epoch value of 0 rather than an accurate one. Correct this bug by sending the correct protocol version in fetchInitialOffset and also ensure we default to `-1` when we decode an OffsetFetchResponse of a Version < 5 Fixes #2694 Signed-off-by: Dominic Evans <dominic.evans@uk.ibm.com>
dnwe
added a commit
that referenced
this issue
Nov 3, 2023
The `fetchInitialOffset` func in offsetManager was hardcoded to send a Version 1 OffsetFetchRequest rather than sending the appropriate version based on the config KafkaVersion. As discussed in #2694 this meant that LeaderEpoch was always being decoded as the default value '0' (because it was only returned in Version >= 5 OffsetFetchRequest). However, other areas of the offsetManager code were sending the newer protocol versions, so for example the OffsetCommitRequest would include a leader epoch value of 0 rather than an accurate one. Correct this bug by sending the correct protocol version in fetchInitialOffset and also ensure we default to `-1` when we decode an OffsetFetchResponse of a Version < 5 Fixes #2694 Signed-off-by: Dominic Evans <dominic.evans@uk.ibm.com>
@kabochya are you able to test against github.com/IBM/sarama@27710af and confirm that you're happy with the fix? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
When using
PartitionOffsetManager
to reset consumer group offsets, we noticed that other consumers kept gettingoffsetEpoch
= 0 inFetchRequest
sI think the culprit is that we are not setting
https://github.com/IBM/sarama/blob/main/offset_fetch_response.go#L7
to -1 by default
in
newPartitionOffsetManager
we invokefetchInitialOffset
which populates thepom.leaderEpoch
. However, we use Version 1 for theOffsetFetchRequest
: https://github.com/IBM/sarama/blob/main/offset_manager.go#L157Since we don't set the
leaderEpoch
for Version < 5 (ref),PartitionOffsetManager
always sets leaderEpoch = 0, which when doing a resetOffset and commit later on, will get committed with the incorrectleaderEpoch
(ref)Versions
Configuration
n/a
Additional Context
Not sure if this could be fixed by having version handling done better in
fetchInitialOffsets
The text was updated successfully, but these errors were encountered: