For non-campaign emails, we use scheduled tasks to display processed stats.
The invalid tasks are no longer processed, and they don't block the queue
and are not counted in the stats.
For campaign emails (bulk emails), we just mark them as sent to zero recipients.
[MAILPOET-5881]
The batch will be continued anyway because of the next condition
if (!$queue->getCountToProcess()) {
continue;
}
The newsletter entity will be marked as sent (plus other stuff related to finished sending)
after the loop in $this->endSending.
In all other cases when we pause sending, we immediately end
the processSending method. In this case, we would unnecessarily
start processing one more batch.
[MAILPOET-5881]
When a post notification history is deleted in
MailPoet\Cron\Workers\SendingQueue\Tasks\Newsletter::preProcessNewsletter
it is also detached from EntityManager.
Any further attempt to manipulate the entity via EntityManager (remove or flush) causes
errors like "ERROR: A new entity was found through the relationship 'MailPoet\Entities\ScheduledTaskEntity#sendingQueue'"
In this commit we prevent doing such changes.
[MAILPOET-5880]
In 3394568, SendingQueue::stopProgress() was refactored to use Doctrine
but a typo introduced a bug causing this method to set
ScheduledTaskEntity::inProgress to true instead of false:
3394568792 (diff-3a26b2d8faf9cc01efd5aef47b058c088c0de01b8074c3be7cefd9adb77fbaaaR551)
This luckly was caught by the
EditorCouponCest.php:seeNoticeWhenCouponCantGenerateAndResumeSending
acceptance test.
This commit fixes the problem and also adds two integration tests to
protect against similar regressions in the future.
[MAILPOET-5682]
We don't need to use the value from `processedAt` here since we can rightfully use the current datetime value
Also, I found out `processedAt` is usually null here for standard newsletters which cause new Carbon to use the server datetime settings
MAILPOET-5795
This will cause the cron job that recalculates engagement score to pick
up these users the next time it runs. This ensures scores don't get
stale.
MAILPOET-5410
getNewsletterFromQueue() has too many conditions under which it returns null. Therefore we can not rely on that method when we wont to delete running tasks with no associated newsletter.
[MAILPOET-4708]
When no corresponding newsletter was found the task can be deleted. The behavior
before meant that such a task would remain forever in the database with the
status 'running'.
[MAILPOET-4699]
