On a site where I use your notification module to send out notifications, your module stopped working suddenly. I will describe my observations below, hoping that it will allow us to find out why this might be happening.

  • Site with 53 users of which 2 are blocked.
  • Only 1 content type gets notification mails sent out.
  • Maximum number of notifications to send out per cron run: 50.
  • Send out new notifications: each cron run.
  • Last notification timestamp: 2017-05-05 18:01:01
  • Status:
    There are 1 node and 0 commentaire created between 05/05/2017 - 18:01 and 05/05/2017 - 20:01.
    No unpublished items.
    No notifications queued.
    No item is flagged for skipping.
    Batch not yet complete. So far 1 e-mail has been sent (1 failure, 1 utilisateur to go).
    The next notification is scheduled for the next cron run.
    Default MailSystem: system default.

Given these settings I observe that with each cron job run:

  • variable notify_users contains 1 user, thus $batch_remain is "true" in _notify_select_content()
  • _notify_select_content() does not return any content or comment that needs a notification for the period between 2017-05-05 18:01:01 and 2017-05-05 20:01:01
  • Thus $count = 0 in _notify_send(), thus variable notify_users does not get reset (no call to variable_set()).
  • Thus !$rest evaluates to false, thus variable notify_send_last does not get updated.

So it looks like there is no longer any advance in sending out notifications. When I deleted the variable notify_users on my test site, the status now becomes:

There are 6 nodes and 2 commentaires created depuis 05/05/2017 - 18:01.
No unpublished items.
Notifications about at least 8 items are queued.
No item is flagged for skipping.
No e-mails were sent.
The next notification is scheduled for the next cron run.
Default MailSystem: system default.

I cannot fully explain how notify_users got set in a time frame that has no notifications to sent, though it might be that content got deleted between the 2 cron jobs needed to sent out the 51 mails. So I think you'd better reset the variable notify_users also if $count = 0.

Does this make sense?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

fietserwin created an issue. See original summary.

fietserwin’s picture

Status: Active » Needs review
FileSize
410 bytes

This is how I solved it for now(I will test further to see if this indeed solves the problem).

fietserwin’s picture

On the live site I did not manually delete the notify_users variable but installed the given patch and ran the batch manually once and indeed the status changed to indicate about new notifications to be sent out. Thus for me the patch works fine.

gisle’s picture

Status: Needs review » Reviewed & tested by the community

This situation should not happen (and it hasn't happened to me yet).

But looking at the code, it is clear that the module will get stuck if notify_users exists and there is nothing to send (i.e. $count is 0). It also seems safe to delete the DB variable in this situation.

So, without being able to reproduce, I've decided to move this to RTBC based on #3.

  • gisle committed 3bc7806 on 7.x-1.x authored by fietserwin
    Issue #2882664 by fietserwin: Notify remains in batch window where there...
gisle’s picture

Version: 7.x-1.3 » 7.x-1.x-dev
Status: Reviewed & tested by the community » Fixed

Patch committed in most recent snapshot of the 7.x-1.x branch

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

5f32525e’s picture

We had the same issue, which started to occur when sending notifications to _too much_ users using a cron run launched with wget. The time took by Drupal to lanch 500 e-mails is longer than the life span of an HTTP request, and wget ended up with « 504 Gateway Timeout ».

* To remove that variable, we used « drush config:edit notify.settings » and manual removal.
* We now moved to a crontab script that runs « drush core:cron »