Unsubscribe links do not unsubscribe


I imported a large forum into discourse (~650k users/3.5 million posts), this requires users to reset their passwords and not all have.

But I have been receiving numerous complaints that people get the digest email, click the unsubscribe link, check “Don’t send me any mail from moparisthebest.com”, click unsubscribe, see the “Unsubscribed! You have been unsubscribed. To change your email settings visit your user preferences.” message, but still continue to get emails. I’ve even received a few angry emails asking me to unsubscribe them.

So, what can I do to make this work as quickly as possible, or maybe unsubscribe everyone in a quick automated fashion? And how do I unsubscribe individual users manually?

(Jeff Atwood) #2

I STRONGLY recommend that you:

  1. Deactivate all old accounts who have not posted in the last 12 months. Otherwise you are signing yourself, and all your users, up for a world of hurt. Remember that in Discourse terminology, deactivated simply means “must validate email address again”.

  2. Disable the weekly digests globally.

This is specific advice to large, old (10+ year) communities that migrate all their data to Discourse.

I am not aware of any bug with unsubscribe. But the defaults you’re using are definitely wrong, and will cause you and your community much pain.

(Felix Freiberger) #3

I suspect that this is happening because you have a large queue of unprocessed jobs. The unsubscribed users will not get new mails enqueued, but the old jobs keep processing.

Can you check /sidekiq for enqueued jobs?


Is this what you mean by disabling weekly digests:

Is there an automated way, perhaps with the console, to do something like deactivating all those users?


There were 3.5 million sidekiq jobs queued after conversion completed, still 1 million plus when people started complaining, I scrolled through a few and didn’t see any email jobs but maybe that was it anyway? The jobs are all complete now.

Should/can unsubscribe remove all pending emails from the sidekiq queue?

(Felix Freiberger) #6

That shouldn’t be necessary. A site that has a sidekiq queue that takes more than a minute to traverse has serious issues anyway – this should certainly never cause in production.

Something that could be improved is the warning to admins. Clearly, you thought that the import was finished while the queue was still running, and I can’t really blame you for that. Maybe the importers should display a super obvious warning that Discourse will need some processing before the import is finished, and / or maybe Discourse should display a very clear warning that the site isn’t ready yet in the header?


I saw the queue was so large so I added more workers to get through it faster, but it still took DAYS, would it have changed anything had I waited for it to finish anyhow?

(Felix Freiberger) #8

It had changed a lot:

  • No emails would have been sent after unsubscribing.
  • New emails would have been sent immediately after they were requested.
  • Many things in Discourse would have started updating correctly immediately.