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

Feature request: Better failures handling while using both BatchProcessing and LargeMessageHandling #596

Closed
qtdzz opened this issue Oct 27, 2021 · 3 comments
Labels
enhancement New feature or request triage

Comments

@qtdzz
Copy link

qtdzz commented Oct 27, 2021

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.

@pankajagrawal16
Copy link
Contributor

pankajagrawal16 commented Oct 27, 2021

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:

public class SqsLambdaHandler implements RequestHandler<SQSEvent, String> {

    @Override
    @SqsLargeMessage(enrichFailureHandler = ExceptionHandler.class)
    public String handleRequest(SQSEvent sqsEvent, Context context) {
        return sqsEvent.getRecords().toString();
    }

    class ExceptionHandler implements EnrichFailureHandler {

        @Override
        public void handleFailure(SQSMessage message,
                                  FailedProcessingLargePayloadException e) {
            // Handle exception specific to a message
        }
    }
}

@qtdzz
Copy link
Author

qtdzz commented Oct 27, 2021

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.

Yeah, I agree. This makes more sense and provides more flexibility.

@jeromevdl
Copy link
Contributor

This will be handled by #797 and #1259

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request triage
Projects
Status: No status
Development

No branches or pull requests

4 participants