-
Notifications
You must be signed in to change notification settings - Fork 89
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
Feature request: Better failures handling while using both BatchProcessing and LargeMessageHandling #596
Comments
What I am thinking is to give possibility to users to handler specific message exceptions while enriching in some way. So if during enriching message from S3, if we get an exception, we can probably accept an exception handler class on LargeMessage annotation which users can implement on how they want to deal with the exception. That way, they can decide themselves, if they would like to throw exception to fail entire batch or would liketo silently deal with the exception and let enriching of other message continue. Something like:
|
Yeah, I agree. This makes more sense and provides more flexibility. |
Is your feature request related to a problem? Please describe.
While using both BatchProcessing and LargeMessageHandling on a lambda, there could be a case when the lambda failed to download the large payload from S3, hence it would fail the whole batch before it could even reach the batch processor. The result is that we have to reprocess/redownload the whole batch, even though most of the messages in the batch could have been processed in the previous try.
Describe the solution you'd like
The failures when downloading payload are handled individually as it were an exception inside the batch processor.
Additional context
My use case is that I would like to batch process large messages. I would prefer to process any messages downloaded successfully without relying on other messages' downloading status. Only the failed-to-load messages should be retried.
The text was updated successfully, but these errors were encountered: