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
Fix a problem in the codebase where we create, schedule and update newsletters in the user time zone, but we set the ProcessedAt with another timezone
Also, `Carbon::createFromTimestamp($this->wp->currentTime('mysql'))` is not a valid date.
It would return date: '1970-01-01 00:35:29.000000'
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]
