Offsets are committed after handler's failure
See original GitHub issueWhen I configure KafkaFlow
with typed handlers, and the handler fails with an exception, the exception message is printed in logs, but the offsets are still committed.
Is it a bug? Or what would be the way of making the consumer to stop and do not proceed further?
Issue Analytics
- State:
- Created a year ago
- Comments:6 (3 by maintainers)
Top Results From Across the Web
Commiting offset after consumer error handling in spring- ...
The failed record can be disposed of via a RecoveryCallback after retries have been exhausted and its offset committed then; the container ...
Read more >Rebalancing during offset commit results in event ...
A normal rebalance does not cause an error when committing offsets; the rebalance is suspended until the next poll; you should only get...
Read more >Kafka Consumer
Offset commit failures are merely annoying if the following commits succeed since they won't actually result in duplicate reads. However, if the last...
Read more >Transaction not getting committed when error handler is ...
If the transaction rolls back the offset is not committed and, by default, seek operations are performed on the consumer so the failed...
Read more >DefaultErrorHandler (Spring for Apache Kafka 3.0.10 API)
An error handler that, for record listeners, seeks to the current offset for each topic in the remaining records. Used to rewind partitions...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Having retries is nice, but there are situations where messages cannot be handled because there is simply a bug in the handler, or if there is a long term outage / breaking API in 3rd party deps, etc. Things like “it won’t be fixed until you deploy a newer version”…
I think that I just expected the default behaviour to be the safest one (stop the world, crash, don’t commit offsets) and everything else would be opt-in. Which is not the case, as I now see.
I’ll have a look at how to write a middleware and what can be done in it, thanks for the advice!
@filipeesch thanks for all your help! Will investigate this option.