Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.When using 8.x with the Update module active, the module will always see Drupal as not-up-to-date. Yet no email is ever sent, due to the following exception that gets thrown when the module causes AutomaticCron::onTerminate to be called, and the request time actually starts invoking cron jobs:
if ($threshold > 0) {
$cron_next = $this->state->get('system.cron_last', 0) + $threshold;
if (REQUEST_TIME > $cron_next) {
$this->cron->run();
}
}
While no mail goes out, the following error appears in the watchdog:
wid: 47
uid: 1
type: cron
message: %type: !message in %function (line %line of %file).
variables: a:6:{s:5:"%type";s:64:"Symfony\Component\DependencyInjection\Exception\RuntimeException";s:8:"!message";s:114:"You have requested a synthetic service ("request"). The DIC does not know how to construct this service.";s:9:"%function";s:43:"service_container_prod->getRequestService()";s:5:"%file";s:171:"/Users/rtoren/projects/drupal8/drupal/sites/default/files/php/service_container/service_container_prod/a1e224f690e8ddf15227b917194424a0d05132adc3cd5f3af47806f418a3aec5.php";s:5:"%line";i:3472;s:14:"severity_level";i:3;}
severity: 3
link:
location:
referer:
hostname:
timestamp: 1399691972
The actual "point of death" is in PhpMail::mail():
// For headers, PHP's API suggests that we use CRLF normally,
// but some MTAs incorrectly replace LF with CRLF. See #234403.
$mail_headers = join("\n", $mimeheaders);
$request = \Drupal::request();
The problem here is the call to \Drupal::request(). I've been able to verify that sometime during the handling of onTerminate, the request object ceases to be available via \Drupal::request() (remember, onTerminate runs only after the browser has received output), if the object is even available. So PhpMail::mail() cannot be called right now this late in the history of the request
Not sure what the fix is, but pretty sure I have the cause down.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | automatic-cron-mail-2266871-07.patch | 4.92 KB | jhedstrom |
| #7 | automatic-cron-mail-2266871-07-TEST-ONLY.patch | 4.16 KB | jhedstrom |
Issue fork drupal-2266871
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
compare
Comments
Comment #1
dawehnerThis is at least major!
Comment #2
jhedstromI wonder if re-weighting the AutomaticCron terminate event would resolve this?
Both
Drupal\Core\EventSubscriber\KernelDestructionSubscriberandDrupal\system\EventSubscriber\AutomaticCronset a weight of 100. If the destruction subscriber goes first, all services are destroyed:Comment #3
jhedstromOops, I had event subscriber priority confused with Drupal weight. The automatic cron should have a higher priority.
Comment #6
jhedstromComment #7
jhedstromI tried to write tests for this, but the one I expect to fail isn't failing...so perhaps this has been fixed? I can clearly see while stepping through the code that
onKernelTerminatedoes get called beforeAutomaticCron, but the test doesn't reproduce the behavior here.Comment #8
mgiffordComment #12
mattshoafThis patch needs to be rerolled,
/core/modules/system/src/EventSubscriber/AutomaticCron.phpis now incore/modules/automated_cronComment #13
jhedstromSo I think the reason that #7's test only patch is passing is that event subscribers with equal priority fire in an indeterminate order. The original error seems to be triggered if the cron subscriber fires after the
onKernelTerminate()method. That being said, I have no idea how to provide a test-only patch that would reliably fire to demonstrate that indeterminacy.