- 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.
- Merge request !12Issue #3264840 by szloredan, manuel.adan: Resending emails are not process from queue → (Open) created by manuel.adan