Resending emails are not process from queue

Created on 16 February 2022, about 3 years ago
Updated 10 September 2023, over 1 year ago

Problem/Motivation

If the email is sent and tried to be resent afterwards in the time which is delayed, the email is added into queue for later processing: DelayedRequestDispatcher.php

The check for the time is to skip the item to be process from queue is:

  if ($confirmation->getCreatedTime() + intval(\Drupal::config('email_confirmer.settings')->get('resendrequest_delay')) < \Drupal::time()->getRequestTime()) {
      throw new RequeueException('Early confirmation request re-send');
  }

If the cron/queue run after the confirmationCreatedTime + resend request delay, the item will be in the queue forever.

Proposed resolution

Change the operator to skip the queue process if current request time is lower then the delay value.

🐛 Bug report
Status

Needs review

Version

1.0

Component

Code

Created by

🇷🇴Romania szloredan

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Assigned to manuel.adan
  • 🇪🇸Spain manuel.adan 🌌

    It is a clear bug. The patch at #3 is valid, but there are additional things to solve related to the request queueing:

    • In the same line (82), comparison is made between the current time and the confirmation creation time. It should be compared with the last time the confirmation request was sent by email
    • Once the main bug is fixed, the involved queue must be cleared or it would start to send old queued confirmation requests that probably are expired or already answered
    • At line 17, the maximum cron processing time is set to just 5". It is a short time, in particular if an email delivery is involved. It should be at least 30"
    • In case of several consecutive request attempts, all of them are queued. If an attempt is already queued for a given confirmation, following requests shouldn't be queued. There is no a good way to check if an item already exists using the Queue API, and rely on DB queue table is not an option since some sites may have another queue backend rather than the default one in core. I think that the best approach to address this is by using the Queue Unique module which exactly provides what is needed. For now it will be just added as a suggestion in composer.json, for next major versions it could be added as a dependency.
Production build 0.71.5 2024