Laravel Mail Queue Infinite Loop on Exception

Question

Hello fellow programmers, I wish everyone a good morning.

The Situation

Laravel is great. Laravel Mail queues and the beanstalkd integration is great. It took me almost no time to get everything working. The sun is shining and its not raining. Its awesome.

Except when an exception is thrown while sending an email. Then thise mail is processed again and again and again and the exception is also thrown again and again and again.

Infinite loop.

I think I wouldnt even notice this if I wouldn't have seeded the database with invalid data. Validation usually would have taken care of that, that emails like 361FlorindaMatthä[email protected] dont end up with the folowing exception:

[Swift_RfcComplianceException]
Address in mailbox given [361FlorindaMatthä[email protected]] does not comply with RFC 2822, 3.6.2.

But what validation wouldnt have taken care for is for example, when my mandrill account reaches its limits or my server looses internet connection, whatever. An Exception sends it into an infinite loop.

In the world where the sun is shining and everything is great the job has to be marked as buried or suspended and the next email should be processed. An infinite loop with an invalid email address is not great.

Basicly your application doesnt send out any emails anymore. This guy has roughly the same issue.

How can I fix this? Has anyone else encountered this Error?

Any Help is much appreciated.

Elsie

Answer 1

You just need to travel Laravel how many times to try a specific job, before deciding it has failed:

php artisan queue:daemon --tries=3

This way, it will stop processing that specific job after 3 tries.

Pyrometallurgy

Answer 2

The hard part of any queue-based system is dealing with the errors, I've run tens of millions of jobs through BeanstalkD and many more through other systems like SQS.

With this Swift_RfcComplianceException exception it's clear that the job will never be able to succeed, and so trying it again would be futile.

Some other problems might be able to be recovered, but in either event, you have to wrap the code in a try/catch block and do what you can.

Since there is no way to 'fix' this particular issue, I would record what happened (the name of the exception and any message, and the data) to a log to check on, and then delete or bury the job. If you store the job-id in the log when it is buried it, you can go back and delete or kick that particular job again later - this would be after being able to change what happens to the job (rather than having it fail again).

Aphanite