emailSender function doesn't use a queue

[SophiaWhiteMA]

The email system could be made easier to use and more reliable by replacing the current system with an email queue. When the emailSender function is called, the email is put into a queue rather than being immediately sent.

Example of how the system currently works (taken from ):

timeoutMS += 500;
setTimeout(() => {
    emailSender(status.email, "New Infringment Assigned", getInfringmentEmailBody(status.firstName, status.lastName, infringment, status.infringments.length), null, "[email protected]");
}, timeoutMS);

the timeoutMS variable is intended to avoid overwhelming the email system. Rather than code this multiple time across the back end, it makes more sense to build this functionality into a queue system.

[one-community]

Questions I have: Are there any potential downsides to this? Would it still work with gmail or use a different email? What are the benefits? You’ve said easier and more reliable, how?

…

On Sep 2, 2021, at 11:51 AM, Cameron White ***@***.***> wrote: The email system could be made easier to use and more reliable by replacing the current system with an email queue. When the emailSender function is called, the email is put into a queue rather than being immediately sent. Example of how the system currently works (taken from <https://github.com/OneCommunityGlobal/HGNRest/blob/development/src/helpers/userhelper.js>): timeoutMS += 500; setTimeout(() => { emailSender(status.email, "New Infringment Assigned", getInfringmentEmailBody(status.firstName, status.lastName, infringment, status.infringments.length), null, ***@***.***"); }, timeoutMS); the timeoutMS variable is intended to avoid overwhelming the email system. Rather than code this multiple time across the back end, it makes more sense to build this functionality into a queue system. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#91>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEL4LES4ITJG5HI3A6TCX7TT77BSHANCNFSM5DJXT4BA>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[SophiaWhiteMA]

Are there any potential downsides to this? None

Would it still work with gmail or use a different email? Same email

What are the benefits? You’ve said easier and more reliable, how?

• It eliminates possible programmer error
• Eliminates the possibility that the emailSender function is called at the same time by two separate threads which can result in one or more emails failing to be sent
• Code becomes significantly easier to maintain and this approach is much better in terms of programming practice / conventions

[one-community]

Sounds good, please proceed. Please add this to the Bugs Doc with your name on it too. I’d say it is “medium” priority.

…

On Sep 4, 2021, at 1:17 PM, Cameron White ***@***.***> wrote: Are there any potential downsides to this? None Would it still work with gmail or use a different email? Same email What are the benefits? You’ve said easier and more reliable, how? It eliminates possible programmer error and eliminates the possibility that the emailSender function is called at the same time by two separate threads which can result in one or more emails failing to be sent. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#91 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEL4LEUXQJY6P4KLWHC77E3UAJ5GDANCNFSM5DJXT4BA>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.