mirror of
https://github.com/zulip/zulip.git
synced 2026-07-21 21:05:48 +08:00
7fd8bfb1c6
Soft-reactivating a returning long-term-idle user backfills the UserMessage rows skipped while they were idle, which can take many seconds. These jobs share the deferred_work queue, which also runs realm exports that can take minutes -- so an optimistic reactivation (enqueued when an idle user is sent a notification or password-reset email, to make their return fast) can sit stuck behind an export and defeat its own purpose. Add an opt-in `dedicated_soft_reactivation_queue` setting that routes these jobs to their own queue and worker. It defaults to off, so that memory-constrained servers keep sharing the deferred_work queue and don't pay for an extra worker process; large servers can enable it to isolate reactivations. The deferred_work handler is deliberately retained: it stays the default path, and also drains soft_reactivate events already queued there when a server enables the dedicated queue. get_active_worker_queues honors the same setting, so a server that hasn't opted in neither runs nor expects the worker, keeping the production-install queue-processor check consistent. The backlog Nagios check only covers the dedicated queue when it is enabled, and gives it the same clear-time thresholds as deferred_work -- the workload it splits off -- so its slow backfills don't trip false alerts. The kandra consumer check is unconditional and assumes the dedicated queue is enabled on those frontends. Fixes part of #22396. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| files | ||
| manifests | ||
| templates | ||