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
How should messages go to the dead letter queue? #30
Comments
I'm pretty sure this is expected behavior. I modeled Lambdakiq after Sidekia & Redis. But after reading the docs again, I do see where we promote the DLQ usage. Damn... maybe you are right and that we should not call |
Also, thank you for the kind words. |
Hi @metaskills thanks for the reply. Sounds good I'll have a shot on a PR and sync back. |
@metaskills I've created the pull request: #31 Thanks! |
Cool, I'll take a look shortly. First sight, it looks amazing and we can release this soon. |
Thank you so much! Released v2.1.0. |
Amazing, thank you! |
Hi all,
Firstly I'd like to thank you all for this amazing piece of software. The work done with lamby/lambdakiq/lambdapunch is awesome and opens up the world of lambda to rails apps. Thanks so much!
I'm a bit confused as to how the dead letter queue redrive functionality from SQS is supposed to work with lambdakiq. I was a bit surprised to find that when my job fails with some exception, my messages actually don't end up in the dead letter queue at all, after the max retries (set either in the redrive policy or in the configs). After looking at the code I can see that once the max retry number is reached, lambdakiq will log retry_stopped and delete the message from the queue. I later noticed that only when something breaks outside of the lamby/lambdakiq handler will that exception actually cause a failed lambda execution and therefore end with the message in the dead letter queue.
I'm wondering if this is how it was all intended to be, or if I'm missing something?
Thanks very much!
The text was updated successfully, but these errors were encountered: