search

jegesh / python-sqs-listener

A simple wrapper for boto3 for listening, and sending, to an AWS SQS queue
Other
154 stars 71 forks source link

Provide some documentation on how to retry without a raise #31

Closed posix4e closed 3 years ago

posix4e commented 5 years ago

Currently in much of our code we rely on the raise to trigger the redelivery functionality. I'm curious if there's a more explicit path I can to re-enqueue the msg easily without a loud raise.

jegesh commented 5 years ago

Do you mean you raise an exception in order to prevent the message from being deleted, thereby allowing it to slip back into the queue after the timeout is reached?

jegesh commented 5 years ago

AFAIK the SQS architecture doesn't allow for that. Once the message is read, it's marked as 'in flight' and can only either be deleted or time out. But maybe there is a way. Have you seen this And this?

posix4e commented 5 years ago

I thought when we crash, the message comes back after the visability timeout. That's fine, i just don't wanna trigger an error

jegesh commented 5 years ago

The listener runs everything in a try - except clause, if that's your concern. The message will come back after the timeout if there's an uncaught exception in handle_message method. If you want the message to always get deleted, you can catch all the exceptions yourself or just use the force_delete kwarg

posix4e commented 5 years ago

What if I want to re-enqueue after timeout with something less noisy then a bare raise

jegesh commented 5 years ago

Then you don't need to do anything. SQS requeues the message after the timeout automatically (unless it's reached its max_retries as defined on the queue).
I feel like either I'm not understanding your question properly, or there's something fundamental that one of us is not getting about the way SQS works. Please elaborate and explain why my previous answers weren't sufficient

posix4e commented 5 years ago

Ahh so just don't return? Wait for forever? My goal is to have it re-enqueued but not to raise? I should just pause? Wont that tie things up?

jegesh commented 5 years ago

Ok, now I understand the issue. Yes, I think raising an exception is the way to go here. If you want it to be requeued immediately, you should try setting the message timeout to 0 as stated above

posix4e commented 5 years ago

ooh great! that’s easy let us add an example in the docs

jegesh commented 4 years ago

I know this thread is kind of stale, but it would be awesome if you could submit a PR with the example we discussed.