Skip to content
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

HighWaterMarkOffset() behaves differently for mocks.Consumer #2050

Closed
jamslinger opened this issue Oct 12, 2021 · 2 comments
Closed

HighWaterMarkOffset() behaves differently for mocks.Consumer #2050

jamslinger opened this issue Oct 12, 2021 · 2 comments
Labels
stale Issues and pull requests without any recent activity

Comments

@jamslinger
Copy link

jamslinger commented Oct 12, 2021

Huh, ok. Unfortunately, consuming a message is the only way I know of to fetch the HighWatermark. If you find another, I'm happy to include it.

Originally posted by @eapache in #1134 (comment)

I encountered the same issue where HighWaterMarkOffset() returns 0 if no messages have been consumed yet. I understand that there is no way to know the HighWaterMarkOffset before the first message has been consumed. However, my problem was that I had tests in place that did not cover that case because mocks.Consumer always returns the "true" HighWaterMarkOffset.

I'd expect mocks.Consumer to also return 0 if no message has been consumed yet. What do you think about that? Otherwise it might be helpful to have that case documented in HighWaterMarkOffset().

dkotvan added a commit to dkotvan/sarama that referenced this issue Jan 6, 2022
The  behavior of the PartitionConsumer is the HighWaterMarkOffset()
method to only return zero until the first message is consumed but the
mocks.PartitionConsumer is updating the HighWaterMarkOffset() every time
the YieldMessage is called.

This commit changes the PartitionConsumer behavior to be the same as the
real PartitionConsumer.

Fix IBM#2050
@github-actions
Copy link

Thank you for taking the time to raise this issue. However, it has not had any activity on it in the past 90 days and will be closed in 30 days if no updates occur.
Please check if the main branch has already resolved the issue since it was raised. If you believe the issue is still valid and you would like input from the maintainers then please comment to ask for it to be reviewed.

@github-actions github-actions bot added the stale Issues and pull requests without any recent activity label Aug 19, 2023
@dnwe
Copy link
Collaborator

dnwe commented Aug 25, 2023

I believe the two are in sync since #2082 but please reopen if that’s not correct

@dnwe dnwe closed this as completed Aug 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale Issues and pull requests without any recent activity
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants