Add delay when queuing multiple debt email

[beesaferoot]

Closes #1299

Brief summary of the change made

Are there any other side effects of this change that we should be aware of?

Describe how you tested your changes?

Pull Request checklist

Please confirm you have completed any of the necessary steps below.

• Meaningful Pull Request title and description
• Changes tested as described above
• Added appropriate documentation for the change.
• Created GitHub issues for any relevant followup/future enhancements if appropriate.

[dmohns]

Hey @beesaferoot

Two comments here

1. How do you know the error is rate limit related? I'm reading the Gmail SMTP relay docs It looks like we should be really far from any limit
   

   Also, I would have expected a rate limit error: https://support.google.com/a/answer/6140680?sjid=6095609842808687166-EU Did we see any of these?

2. Regarding the actual implementation. Can't we just use a queue-based Rate Limit? https://laravel.com/docs/12.x/queues#rate-limiting instead of a custom delay implementation? We could even go further and at exponential backoff retries on queue level.

[beesaferoot]

1. How do you know the error is rate limit related? I'm reading the Gmail SMTP relay docs It looks like we should be really far from any limit

This link (https://support.google.com/a/answer/3221692) was part of the error message, I did a little search on the cause of issues like this. I came across this (https://forum.mautic.org/t/error-sending-emails/25498/2), also asked ChatGPT.

I know our IP isn't banned entirely because we still successfully send out emails in other cases (i.e., welcome email etc), but there appears to always be an error when trying to send out debt emails. What do you suggest? without making uninformed guess, I'm not sure what to make of it yet.

Regarding the actual implementation. Can't we just use a queue-based Rate Limit? https://laravel.com/docs/12.x/queues#rate-limiting instead of a custom delay implementation? We could even go further and at exponential backoff retries on queue level.

This is a better solution. I will look into it. Thank you

[dmohns]

1. How do you know the error is rate limit related? I'm reading the Gmail SMTP relay docs It looks like we should be really far from any limit

This link (https://support.google.com/a/answer/3221692) was part of the error message, I did a little search on the cause of issues like this. I came across this (https://forum.mautic.org/t/error-sending-emails/25498/2), also asked ChatGPT.

I know our IP isn't banned entirely because we still successfully send out emails in other cases (i.e., welcome email etc), but there appears to always be an error when trying to send out debt emails. What do you suggest? without making uninformed guess, I'm not sure what to make of it yet.

Yeah, this is really tricky to understand. I'm just curious because they provide such a detailed list of SMTP Error codes: https://support.google.com/a/answer/3726730?sjid=16209648178720520903-EU

For example

550 5.7.1 This email has been rate limited.

Interestingly, the error already gives us some indication. Try again later, 😂 Are we retrying email sending?

Regarding the actual implementation. Can't we just use a queue-based Rate Limit? https://laravel.com/docs/12.x/queues#rate-limiting instead of a custom delay implementation? We could even go further and at exponential backoff retries on queue level.

This is a better solution. I will look into it. Thank you

👍

[beesaferoot]

Interestingly, the error already gives us some indication. Try again later, 😂 Are we retrying email sending?

Yes but it doesn't have any backoff logic; it simply retries immediately