# 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:** [21.Март.2019 22:15:00 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:** 10

<div class="post-metadata">

**Author:** ![neil](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/neil/32/102150_2.png) [@neil](https://meta.discourse.org/u/neil)\
**Post date:** [22.Март.2019 13:28:20 UTC](https://meta.discourse.org/t/users-receive-multiple-summary-emails-when-sidekiq-queue-is-30-minutes/112291/10 "2019-03-22T13:28:20Z")

</div>

> [@pfaffman](#):
>
> 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)

I think this is a good solution too. Summary emails (and many others) are put into the low-priority queue, so are most likely to be delayed when sidekiq has a lot of jobs to process. I don’t think it’s too much of a hack to check last\_emailed\_at if it’s a digest email in [here](https://github.com/discourse/discourse/blob/master/app/jobs/regular/user_email.rb#L18-L24).

---

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