mirror of
https://github.com/zulip/zulip.git
synced 2025-10-23 04:52:12 +00:00
c5200e8b05
`deliver_scheduled_emails` tries to deliver the email synchronously, and if it fails, it retries after 10 seconds. Since it does not track retries, and always tries the earliest-scheduled-but-due message first, the worker will not make forward progress if there is a persistent failure with that message, and will retry indefinitely. This can result in excessive network or email delivery charges from the remote SMTP server. Switch to delivering emails via a new queue worker. The `deliver_scheduled_emails` job now serves only to pull deferred jobs out of the table once they are due, insert them into RabbitMQ, and then delete them. This limits the potential for head-of-queue failures to failures inserting into RabbitMQ, which is more reasonable than failures speaking to a complex external system we do not control. Retries and any connections to the SMTP server are left to the RabbitMQ consumer. We build a new RabbitMQ queue, rather than use the existing `email_senders` queue, because that queue is expected to be reasonably low-latency, for things like missed message notifications. The `send_future_email` codepath which inserts into ScheduledEmails is also (ab)used to digest emails, which are extremely bursty in their frequency -- and a large burst could significantly delay emails behind it in the queue. The new queue is explicitly only for messages which were not initiated by user actions (e.g., invitation reminders, digests, new account follow-ups) which are thus not latency-sensitive. Fixes: #32463.
9 lines
283 B
Python
9 lines
283 B
Python
# Documented in https://zulip.readthedocs.io/en/latest/subsystems/queuing.html
|
|
from zerver.worker.base import assign_queue
|
|
from zerver.worker.email_senders_base import EmailSendingWorker
|
|
|
|
|
|
@assign_queue("email_senders")
|
|
class ImmediateEmailSenderWorker(EmailSendingWorker):
|
|
pass
|