-
Notifications
You must be signed in to change notification settings - Fork 53
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
Error after upgrading to v0.3.2 #78
Comments
Can you try replacing this line: 595d7a2#diff-b6e1efdb0ead446a507e7c9ce19ce2ef9575981439c063c0bea6cf5697711778R146 by:
And let us know if it works? |
Which kafka version are you using? |
already tried that, using |
2.2.1 |
hey @josevalim I think we need to re-open this issue.
In there, I already have an offset, which as far as I can tell is valid, and that's why this has been working up until 0.3.1 (where it broke) Now, in the next versions (lets use 0.3.3) having an offset in current_offset is not enough, and goes through one more validation step where it manually calls :brod.fetch https://github.com/dashbitco/broadway_kafka/blob/v0.3.3/lib/broadway_kafka/brod_client.ex#L142 The error is the same one i reported on top of this thread:
Just to be clear, the actual consumption of messages is not broken, I can fetch records all right. But the offset is reset to 0 after each deploy. |
Thanks for the updates, a new PR is welcome! |
Awesome. I'll keep researching |
Hey there, I seem to be facing an issue that I think got introduced in 595d7a2
Here, :brod.fetch is expected to return {:ok, _} or {:error, :offset_out_of_range}
But the spec of :brod.fetch says the error tuple is
:error, any
, and I seem to be facing that, as what I get isI'm not familiar with the inner workings of this library, but should the error tuple be relaxed to any error tuple?
My setup works again if I downgrade to v0.3.1
Thank you!!
The text was updated successfully, but these errors were encountered: