Consider supporting manual message acknowledgement

[rnegron]

I wanted to re-surface a suggestion made a couple of years ago (https://github.com/bbc/sqs-consumer/issues/35): optionally leaving messages in the queue after receiving them. As explained here: https://github.com/bbc/sqs-consumer/pull/36#issuecomment-222935632, I understand that this library was intended to be an abstraction around the entire capture-and-acknowledge process. However, it is quite surprising that in order to halt message acknowledgement for any reason, I am forced to throw an error in the handler function. This forces non-semantic behavior, in my opinion (an error occurring is not the only reason I may not want to acknowledge the received message). The catch block says'Unexpected message handler failure', but why not support "expected" errors?

Since the processMessage function makes use of other private (and not protected) methods, inheriting from the class currently is not ideal...

I propose three possible solutions...

1. As was previously suggested, an optional flag (with default set to current behavior).
2. Opening the Consumer class up a little to allow for easy class extension.
3. Modifying the executeHandler method to return some sort of flag that controls whether or not to delete the message.

Please let me know what you think. I would be happy to provide a Pull Request if the suggestion is accepted!

[crh3675]

I like this idea in the consumer creation. Something with configuration on startup such as handleMessageAckMethod with three values, default, rejectContinue, rejectStop. Meaning, the default behavior is to acknowledge first but if someone chooses the others, return of handleMessage or handleMessageBatch must resolve() before being deleted from the queue.

As well, if someone chooses rejectContinue, the message in the reject is simply logged but if rejectStop is the setting, the message is logged and polling stops. Final option might be that the new handleMessageAckMethod might even accept a custom function that a user might want to create.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[rnegron]

🤷🏻