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.
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]
I opted to remove testItDeletesQueueWhenNewsletterIsNotFound() as I
wasn't sure how to recreate this test using Doctrine and I found out
that it was actually not working. The call to
$this->newslettersRepository->bulkDelete() was deleting the sending
queue entry and not SendingQueue::deleteTaskIfNewsletterDoesNotExist().
[MAILPOET-5737]
This test was checking that the status of a welcome email is set to
`sent` after it is processed. Turns out this is not what should happen
and also not what is actually happen. The code only changes the status
of emails of the types standard and notification history:
7d43059f15/mailpoet/lib/Cron/Workers/SendingQueue/Tasks/Newsletter.php (L285-L286)
The test changes the type of the email to welcome
using Paris and never persists it to the database. The code mentioned
above that changes the status of the email uses Doctrine, so it was
still acting as if this was an standard email and not a welcome email.
To fix this problem, I updated the test to check if the status of the
welcome email is `active` and also made sure to persist the change to
the database and refresh the Doctrine entity.
[MAILPOET-5737]
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]
While working on the previous commit, I noticed that we had a test to
check removing subscribers that are not part of a segment associated
with a newsletter when sending
(testItRemovesSubscribersFromProcessingListWhenNewsletterHasSegmentAndSubscriberIsNotPartOfIt()).
But SendingQueue::processSending() also handles removing subscribers
when sending newsletters without segments. And there was not test to
cover this part of the code.
[MAILPOET-5682]
This commit also removes Sending::getSendingQueueEntity() as the last
calls to this method were removed when refactoring SendingQueueTest.
[MAILPOET-5682]
It was necessary to update a test to be more lenient when comparing
dates and another one to persist a change in Paris to the database.
[MAILPOET-4368]
