# Users receive multiple summary emails when sidekiq queue is \>30 minutes

**URL:** <https://meta.discourse.org/t/users-receive-multiple-summary-emails-when-sidekiq-queue-is-30-minutes/112291>\
**Category:** Self-hosting\
**Created:** [March 21, 2019, 10:15pm UTC](https://meta.discourse.org/t/users-receive-multiple-summary-emails-when-sidekiq-queue-is-30-minutes/112291 "2019-03-21T22:15:00Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)\
**Post date:** [March 22, 2019, 11:38am UTC](https://meta.discourse.org/t/users-receive-multiple-summary-emails-when-sidekiq-queue-is-30-minutes/112291/7 "2019-03-22T11:38:35Z")

</div>

I think I’ve identified a race condition. I know that the sidekiq queue had a 10K second (~3 hour) latency. Messages are queued every 30 minutes:

> <https://github.com/discourse/discourse/blob/main/app/jobs/scheduled/enqueue_digest_emails.rb#L3-L4>

So a digest gets queued in an hour-long queue. Half an hour later we test for whether to queue another digest, checking the last time that a message was sent:

> <https://github.com/discourse/discourse/blob/main/app/jobs/scheduled/enqueue_digest_emails.rb#L22>

The last digest is **queued** , but not **sent** , so `last_emailed_at` isn’t updated, so another message gets queued.

The solutions that I see are:

1. this site gets faster hardware (beyond my control)
2. `target_user_ids` somehow searches the queue to see if there is a queued, unsent digest (seems really hard and won’t get into core in my lifetime).
3. Have the process that **sends** the digest do another check of `last_emailed_at` before sending the digest (I think this might be the best long-term solution, but haven’t found that code)
4. I add a hook to modify `enqueue_digest_emails.rb` to make `every 30.minutes` something like `4.hours` (6 hours?) and hope that is enough time for the queue to get processed before it runs again.

Number 4 above seems like my only immediate solution. Is there some deleterious side effect that I am overlooking?

(I did recently increase `db_shared_buffers` from 10GB to 16GB for the 30GB on disk database. This might help, but I suspect that it won’t be enough. There are ~25K users at TL1 and above.)

---

_[View the full topic](https://meta.discourse.org/t/users-receive-multiple-summary-emails-when-sidekiq-queue-is-30-minutes/112291)._