When queue is not running and scheduler is, mailator overfloods the queue

[dstollie]

Context

We came in a situation w here the our queue was not running. After a few hours we've seen this and started the queue. Immediately the queue was being cleared. From so far, everything looked fine until we saw that Mailator dispatched the same mail everytime.

The problem

The problem here lies that the scheduler from mailator see that the mail has not yet been sent and disptaches a new job onto the queue. Normally this is no problem but when the job is STILL on the queue, this is a problem. In our situation we had a few customers receiving more than 100 mails.

This is a serious problem for us because it can happen in the future that the scheduler is running but the queue is not, how can we avoid this problem, does the author have an idea?

[drmmr763]

hello @dstollie I just found out I am having the exact same issue you describe here. If the queue is backlogged or the processor stops running, the mail is queued many times and then floods the recipient when the the processor catches up.

Did you ever come up with a solution to this? I am thinking I may need to write a beforeSend function to check if its been sent already so even if it does queue up, the other jobs will self-cancel before going out.

@maloun96 do you happen to have any thoughts?

[drmmr763]

Just following up for anyone else: I think I was able to figure out how to prevent this double queuing / sending problem. There's two (maybe 3) keys when you initialize the scheduled mail:

\Binarcode\LaravelMailator\Scheduler::init('Reminder Email')
  ->once()
  ->recipients($this->user->email)
  ->actionClass(new SendMailActionWithoutDuplicates())
  ->constraint(new OnceConstraint())

Calling ->once() and adding the OnceConstraint seemed to help. I tested this by turning off all automated queues, schedulling a mail with a command, running php artisan schedule:run a few times and then running php artisan queue:work --once --queue=mail to verify that only 1 mail is sent.

I do also have a custom action sending class where I attempted to override the normal send and do a check and cancel if the completed_at column was not-null. However, in my logs I don't think this is hit at send-time and seems to hit at queuing time, so it doesn't really make a difference.