We use action_scheduler_maximum_execution_time_likely_to_be_exceeded filter for reading remaining execution limit
tracked in the Action Scheduler runner.
Then we use the remaining limit minus safety margin for the daemon execution.
[MAILPOET-4274]
In afterProcess callback we trigger a new runner when there are still some scheduled tasks
to process. Before this change we did this for every action scheduler run and it was causing that
we triggered more HTTP requests than needed.
[MAILPOET-4274]
In the process it was necessary to change the signature of the method
\MailPoet\Mailer\MetaInfo::getNewsletterMetaInfo() to accept a
SubscriberEntity instead of a Subscriber model and also change
\MailPoet\Cron\Workers\SendingQueue\SendingQueue::processQueue() as it
calls getNewsletterMetaInfo().
Doing this was straightforward, but changing the test class for
SendingQueue was a bit more involved. In particular, the test
SendingQueueTest::testItEnforcesExecutionLimitsAfterQueueProcessing().
This test is a bit brittle and was creating Subscriber models without
saving them to the database with invalid statuses and sources. Switching
getNewsletterMetaInfo() to use entities, while
SendingQueue::processQueue() still uses models, meant that it was
necessary to save the subscribers to the database. Because of this, it
was not possible anymore to use invalid statuses and sources, and
thus, the test changed a bit.
[MAILPOET-4379]
This allows to configure a special URL base for cron.
Cases here are dev environments, but also potentially intranet sites or anything else with an atypical network layout
[MAILPOET-4406]
Majority of scheduled tasks DB records are completed tasks.
We check completed tasks only for Migration worker task type.
Excluding other workers' completed tasks significantly speeds up the query
on sites with longer history. E.g. on mailpoet.com the query sped up from 0.6s to 0.003s.
[MAILPOET-4314]
By default checkRunInterval will always return true because there is no way
the time which has passed since the last run is smaller than -1. To prevent
unnecessary code execution and an not needed SQL insert, we can return true
in checkRunInterval() early.
[MAILPOET-4267]
We can't create mailer directly in DI container using the factory because it may fail in case
the plugin is not configured properly and prevent plugin from start.
The Mailer was previously injected because it contains lazy initialization.
The lazy initialization in the singleton Mailer service was dangerous,
because when used with some custom parameters it could cause that all services
that inject the Mailer from DI would use the custom config instead the default.
[MAILPOET-4115]
