mirror of
https://github.com/zulip/zulip.git
synced 2026-06-30 21:11:04 +08: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. |
||
|---|---|---|
| .. | ||
| lib | ||
| nagios | ||
| setup | ||
| __init__.py | ||
| get-django-setting | ||
| log-search | ||
| purge-old-deployments | ||
| README.md | ||
| refresh-sharding-and-restart | ||
| reload-clients | ||
| restart-server | ||
| start-server | ||
| stop-server | ||
| upgrade-zulip | ||
| upgrade-zulip-from-git | ||
| zulip-puppet-apply | ||
This directory contains scripts that:
-
Generally do not require access to Django or the database (those are "management commands"), and thus are suitable to run operationally.
-
Are useful for managing a production deployment of Zulip (many are also used in a Zulip development environment, though development-only scripts live in
tools/).
For more details, see https://zulip.readthedocs.io/en/latest/overview/directory-structure.html.