NotifyMailingListSubscribers execute not fired when user posts new topic


(Paul Apostolos) #1

A user posted a new topic to the forum, but the none of the mailing list notification emails were sent. They don’t show up in the email logs and there are no errors in logster.

I thought perhaps the user didn’t have permission to mail to the list, but he is trust level 2 and his settings seem pretty standard. He’s active and approved.

Is there some specific setting that could be causing regular users to not be able to notify the mailing list subscribers?

(I have tested the send mail functionality a few times and that works for different email addresses)


(Paul Apostolos) #2

This is still happening. When a user of our Discourse forum submits a post, it should be sent to all users that have the mailing_list option set. (Currently about 700 do).

Another user just submitted a topic an nothing went to the list. The notifications (little bubble in the top right) are there for users. But, no mail was sent (I am looking at the Email -> Sent tab in the admin).

Test email works just fine and if I post a topic, the mailing list is notified.

I am stumped.


(Jeff Atwood) #3

Not sure, @sam can you have a look? If mailing list mode is on, all posts and topics should trigger an email for users with that flag set.


(Paul Apostolos) #4

After importing our production data into a Vagrant instance (with MailCatcher), I was able to watch the process in detail.

We have roughly 700 users signed up to receive the mailing list notifications. (maybe I’m wrong, but I don’t think that number is outrageous)

When a Post is saved the after_post_create method of the Post calls

Jobs.enqueue_in(
    SiteSetting.email_time_window_mins.minutes,
    :notify_mailing_list_subscribers,
    post_id: @post.id
)

notify_mailing_list_subscribers loops through all users signed up to receive the mailing list notifications and adds them to the Job. For 700 users that can take some time and while that is happening the bottom of the user’s screen reads “Saving”.

I think something is happening during that Saving that aborts the transaction for the enqueue of the Job to notify the mailing list subscribers.


(Jeff Atwood) #5

Good detective work. @sam anything we should look at here with hundreds or thousands of users having mailing list mode set?


(Sam Saffron) #6

The enqueue is pretty close to a not op, the actual works happens in the job itself which first in “email_time_window_mins”, which is 5 minutes out of the box.

Perhaps you want to reduce the site settings default (which means that grace period edits will not be picked up which can be annoying)

Can you look at the error logs after waiting email_time_window_mins to see if anything pops up there?


(Sam Saffron) #7

Are you certain that in your dev instance, queue_jobs is ticked?


(Paul Apostolos) #8

The queue box is checked.

You can see in the screencast I sent you that the job does get scheduled and is displayed in the scheduled tab of Sidekiq. My suspicion is that because it takes a long time to get there, it is prone to failure. That process takes 20 - 30 seconds on my local machine.


(Sam Saffron) #9

Look in MiniProfiler after you submit it, what are the repeated queries? where are they coming from?

You get there by clicking the small number in top left, and then clicking sql.


(Sam Saffron) #11

I see what you have going on here, you have 700 users watching this topic. that is causing major pain.

Have you automated “category” watching for all these users?


(Paul Apostolos) #12

@sam you totally should have said, “Well there’s your problem!”

(from knowyourmeme.com)

That was totally it. I removed the category watches and mutes from all users and it is working great.

We had two mailing lists previously and users subscribed to the different lists. I imagined the category watching was the correct way to implement that. Turns out, I was wrong. Is category muting for the old mailing lists that the user is NOT subscribed to the correct way to implement that?


(Jeff Atwood) #13

I would assume mutes are safer than watches, since mutes are a rejection check. But @sam would have to answer definitively.

(We even respect category mutes in the digest email now)