Fatal Error in Cron Job Enabling/Disabling Staging Updates for Cart Rules #9788
Description
Preconditions
PHP 7.0.19, MariaDB 10.0.30, Magento 2.1.6 EE w/ Sample Data (Installed from .tar.gz bundle)
Debian 8.8 jessie Vagrant environment
Bug also confirmed in production environment on CentOS, M2.1.5
Steps to reproduce
- Ensure no bin/magento cron:run is automatically running through crond, so you can manually run this on the command line.
- Create a new Cart Rule, with website selected and all customer groups. Leave rule disabled.
- Add rule to a scheduled update. On the update, set a start date that's a few minutes in the future, and an end date that's a few minutes after that. Set the update to Enable the rule when it is processed, but no other changes are needed in order to trigger this bug.
- When it's just before update is scheduled to fire, start running bin/magento cron:run from the command line and observe output. If no error occurs, wait 30 seconds and run it again. The majority of the time, the bug triggers when the rule is enabled, but not 100% of the time.
- I no error occurs, keep running bin/magento cron:run on the command line until it processes the scheduled update to disabled the cart rule. The error also triggers most of the time when the rule is disabled, but sometimes it doesn't appear.
- If you don't encounter the error, just make a new scheduled update and repeat a few times until you see it.
Expected result
No errors.
Actual result
When the cron:run determines it needs to process the scheduled update for the cart rule and triggers the code to do so, it appears that the rule is correctly enabled or disabled. However, in addition, most of the time a PHP fatal error will be output to the console:
root@jessie:/var/www/html# bin/magento cron:run
Ran jobs by schedule.
root@jessie:/var/www/html# bin/magento cron:run
Ran jobs by schedule.
root@jessie:/var/www/html# bin/magento cron:run
Ran jobs by schedule.
root@jessie:/var/www/html# bin/magento cron:run
Ran jobs by schedule.
root@jessie:/var/www/html# bin/magento cron:run
Ran jobs by schedule.
root@jessie:/var/www/html# PHP Fatal error: Uncaught TypeError: Argument 1 passed to Magento\SalesRule\Model\RuleRepository\Interceptor::save() must be an instance of Magento\SalesRule\Api\Data\RuleInterface, instance of Magento\SalesRule\Model\Rule\Interceptor given, called in /var/www/html/vendor/magento/module-staging/Model/StagingApplier.php on line 148 and defined in /var/www/html/var/generation/Magento/SalesRule/Model/RuleRepository/Interceptor.php:20
Stack trace:
#0 /var/www/html/vendor/magento/module-staging/Model/StagingApplier.php(148): Magento\SalesRule\Model\RuleRepository\Interceptor->save(Object(Magento\SalesRule\Model\Rule\Interceptor))
#1 [internal function]: Magento\Staging\Model\StagingApplier->execute(Object(Magento\Cron\Model\Schedule))
#2 /var/www/html/vendor/magento/module-cron/Observer/ProcessCronQueueObserver.php(247): call_user_func_array(Array, Array)
#3 /var/www/html/vendor/magento/module-cron/Observer/ProcessCronQueueObserver.php(195): Magento\Cron\Observer\ProcessCronQueueObserver->_runJob(1496067720, 1496067801, Array, Obj in /var/www/html/var/generation/Magento/SalesRule/Model/RuleRepository/Interceptor.php on line 20
Now pay close attention! Notice that when the final bin/magento cron:run was executed from the command line, the command exited and returned me to a shell prompt. It was AFTER this point that output was displayed from a background task that was still connected to the terminal stdout or stderr.
This implication of this is that when bin/magento cron:run is executed from crond, it is likely crond never sees output to be logged or emailed to the admin user, since the command exited successfully before a background task sends error output. I have checked my logs and never found this error in cron logs. Only when I manually process scheduled updates of catalog rules from the command line. This bug likely impacts all cron jobs on M2 sites, though, and nobody is ever informed.
Note that it appears that the cron:run successfully processes the scheduled update. This bug triggers a PHP fatal error, but it does not appear to impact functionality. I have not dug deeply into what's going on, though, so there may be some other effects I'm not aware of.
I have confirmed this bug on our live production site running M2.1.5 EE, as well as Vagrant boxes built based on our production codebase. To ensure this was really a core M2 bug, I just installed M2.1.6 EE with sample data on a Vagrant box and was able to produce the bug on that system as well.