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]
The goal of this commit is to change the preProcessNewsletter method
to return false only in case when it deleted the newsletter and
all associated entities. So that we know for sure that false means all was deleted.
[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]
In 862c395d3263f30057aef73a14704345e181dde3, SendingErrorHandler was
refactored to replace the `\MailPoet\Tasks\Sending` class with Doctrine
code. Inside `processSoftError()`, a call to
`$sendingTask->saveSubscriberError()` was replaced with a call to
`$this->scheduledTaskSubscribersRepository->saveError()`. The problem is
that the former updates the processed and unprocessed counts in the
QueueEntity while the later doesn't.
This commit fixes this issue by calling
`$this->sendingQueuesRepository->updateCounts()` inside
`processSoftError()`.
[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
As far as I could test, calling validate() directly is not necessary.
The call to $sendingTask->save() right above calls validate() internaly
and then any errors will be returned by $sendingTask->getErrors().
I added a integration test that seems to confirm this interpretation.
[MAILPOET-4693]
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
