You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using an SQS handler, it seems that including an exit; anywhere in the code for debugging causes the lambda to go into an infinite loop. Is this expected? Is there a better alternative for debugging that does the equivalent?
Yes, by halting the process with exit or die, you prevent Bref from successfully executing the job so the SQS message stays in the queue and gets picked up again. When it gets picked up again, it exits again, leading to an infinite loop. This is caused by the design priniple of queueing systems. If you pick up a work and fail to finish it, it will be retried.
What you're experiencing is mostly referred to as a poisonous pill. There is a message (pill) on your queue which is broken (poisonous). Anytime a worker pick it up, it fails and the message stays in the queue. Mitigations technique involves limited amount of retrials (defining maximum execution for jobs) and visibility timeout (how long until a message stays invisible until it is made available again).
For debugging, you'd be better off writing to STDERR or using a logging mechanism and logging data you want to see.
We have no retries on the queue and 3 min visibility timeout; if the script was ending prematurely and then getting hit by SQS again and again I would understand that, but it seems like it's actually bref doing this... it's a strange behavior.
Either way, I appreciate the clarification and hope this helps future people who end up in the same situation! Thanks! 😀
SQS has infinite retries by default with message duration for up to 14 days. The only way to not have retries is to actually have an SQS Dead Letter Queue. Laravel retry mechanism is different than SQS retry mechanism.
Does Bref run your message exactly 3 times very fast and then the message goes into Visibility Timeout for 3 minutes? Because AWS Lambda also have an automatic retry configured by default to 2 attempts (1 + 2 retries)
Q: What happens if my Lambda function fails while processing an event?
On failure, Lambda functions being invoked synchronously will respond with an exception. Lambda functions being invoked asynchronously are retried at least 3 times. Events from Amazon Kinesis streams and Amazon DynamoDB streams are retried until the Lambda function succeeds or the data expires. Kinesis and DynamoDB Streams retain data for a minimum of 24 hours.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello,
When using an SQS handler, it seems that including an exit; anywhere in the code for debugging causes the lambda to go into an infinite loop. Is this expected? Is there a better alternative for debugging that does the equivalent?
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions