Right now TWLight sends email as part of the request-response loop. This will do for now but will rapidly become untenable with scale. The djmail system can have other backends swapped in - its expected option for async email sending is to use celery, which requires setting up celery and a broker for it and editing settings/production.py accordingly.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Invalid | None | T170977 Post-migration issues and priorities | |||
| Resolved | jsn.sherman | T149436 Add async email-sending strategy |
Event Timeline
Comment Actions
@jsn.sherman you might want to take a look at this to decide on priority, I'm not sure how much of a concern this will be.
Comment Actions
After doing some research on this, I recommend ditching direct emails for communicating with editors and coordinators, and instead leverage the email user api to have the wiki infrastructure send the mail on our behalf.
We'll still need to send our own mails to partners, but that should be much lower volume. We could even bring those out of the platform by just generating mailto links with the correct information filled in.
Comment Actions
Django has some decent email testing tools that we should probably be using. DJmail, which is our current mail handling library, has some asynchronous options that don't have external dependencies, but I'll need to get at least some basic email testing in place before we can reconfigure it.
Comment Actions
Quick update: I'm currently testing using an async djmail backend for sending mail. Currently, it offers all of the hoped for performance benefits of an async mail queue, minus the capability to actually transfer any email messages. In other words, I'm making progress, but I still have a little work to do.
Comment Actions
async email config pushed to prod. Testing turned up a few more cases where there the user salutation ended up being the numerical ID T169525. It was down to the fact that we're using a separate system for app comments than for the rest of the things that generate emails. That's now been resolved as well.
This should really only make a perceivable difference in page loads that are causing a lot of emails to be sent. Eg. waitlisting a partner with a lot of applications previously took a very long time to complete, or timed out.