Opened 4 years ago
Closed 9 days ago
#34477 closed New feature (needsnewfeatureprocess)
Asyncio send mail backend
| Reported by: | Andrew Chen Wang | Owned by: | Ahmed Ibrahim |
|---|---|---|---|
| Component: | Core (Mail) | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | Ahmed Ibrahim, Mike Edmunds | Triage Stage: | Accepted |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description (last modified by )
Implementation of asyncio send mail functionality. All methods get its a prefix variant, and the get_connection runs a start command unlike its sync version.
https://github.com/django/django/pull/16744
Adds Base, Console, and Dummy backends (no test; pending review of draft implementation).
Change History (9)
comment:1 by , 4 years ago
| Description: | modified (diff) |
|---|---|
| Needs documentation: | set |
| Needs tests: | set |
comment:2 by , 4 years ago
| Owner: | changed from to |
|---|---|
| Patch needs improvement: | set |
| Status: | new → assigned |
| Triage Stage: | Unreviewed → Accepted |
comment:3 by , 3 years ago
| Easy pickings: | unset |
|---|
comment:4 by , 16 months ago
| Cc: | added |
|---|---|
| Has patch: | set |
| Needs tests: | unset |
| Owner: | changed from to |
| Version: | 4.2 → dev |
I will handle this since it became inactive and I think it's a neat feature
comment:5 by , 16 months ago
| Has patch: | unset |
|---|---|
| Needs documentation: | unset |
| Patch needs improvement: | unset |
follow-up: 8 comment:6 by , 16 months ago
Would it be better if I leave the sync implementations as is, and add a new async implementation, because I my mind tells that we can create the async and use the async to create a new sync handler with sync_to_async so that the logic is only in one place
comment:7 by , 16 months ago
| Cc: | added |
|---|
comment:8 by , 16 months ago
Replying to Ahmed Ibrahim:
Would it be better if I leave the sync implementations as is, and add a new async implementation, because I my mind tells that we can create the async and use the async to create a new sync handler with
sync_to_asyncso that the logic is only in one place
My instinct is that each EmailBackend should decide for itself whether to implement send_messages(), asend_messages(), or both. And then maybe the BaseEmailBackend implementation could sync_to_async or async_to_sync if a subclass only provides one of them. (But I'd need to think some more about what happens if an existing sync send method gets asyncified.)
comment:9 by , 9 days ago
| Resolution: | → needsnewfeatureprocess |
|---|---|
| Status: | assigned → closed |
I'm going to bounce this over to the new features process. Now that Django's tasks framework is available (DEP-14), we may want to revisit the idea of adding async methods throughout django.core.mail.
There's an argument that tasks are sufficient for decoupling mail sending from requests processing and similar "main-thread" operations. Even if there is still interest in async email sending in Django core, we might now want to limit it to lower-level APIs that could be called from within a task handler—rather than asyncifying the entire set of core mail functions. (E.g., offering amail_admins() seems like a potential footgun, vs. encouraging offloading that sort of notification to a task queue.)
Accepted based on DEP-9.