Event ECA Cron Event getting error "function get() on null"

This doesn't like an ECA issue. Something accesses the cache collector from Drupal core. That's a core service that receives the cache backend when being initialized. That cache backend is supposed to be NULL according to the error message you receive.

I can only think of some misconfiguration on that Drupal site.

If you doubt that's the case, please provide detailed steps on how to reproduce this issue on a fresh Drupal site.

Hi @jurgenhaas, I have tried fresh Drupal installation 10.3.1 with standard setting, and only install ECA 1.1.7 with BPMN.io 1.1.4.

The problem still occured. can you help? please thank you

I just started seeing this too, after enabling an ECA model that used the cron event. (Cron runs from crontab using wget.) I also updated Drupal core to 10.3.1 and hook_event_dispatcher to 4.0.3 about the same time. ECA is 1.17.

Here's a traceback in case it helps:

Error: Call to a member function get() on null in Drupal\Core\Cache\CacheCollector->lazyLoadCache() (line 352 of /home/xxxxxxx/public_html/web/core/lib/Drupal/Core/Cache/CacheCollector.php)

#0 /home/xxxxxxx/public_html/web/core/lib/Drupal/Core/Cache/CacheCollector.php(144): Drupal\Core\Cache\CacheCollector->lazyLoadCache()
#1 /home/xxxxxxx/public_html/web/core/lib/Drupal/Core/State/State.php(80): Drupal\Core\Cache\CacheCollector->get('timestamp.cron-...')
#2 /home/xxxxxxx/public_html/web/modules/contrib/eca/src/EcaState.php(77): Drupal\Core\State\State->get('timestamp.cron-...', 0)
#3 /home/xxxxxxx/public_html/web/modules/contrib/eca/modules/base/src/Event/CronEvent.php(105): Drupal\eca\EcaState->getTimestamp('cron-Event_06cl...')
#4 /home/xxxxxxx/public_html/web/modules/contrib/eca/modules/base/src/Event/CronEvent.php(71): Drupal\eca_base\Event\CronEvent->isDue('Event_06clj7s', '0 2 * * *')
#5 /home/xxxxxxx/public_html/web/modules/contrib/eca/src/Entity/EcaStorage.php(106): Drupal\eca_base\Event\CronEvent->appliesForLazyLoadingWildcard('Event_06clj7s::...')
#6 /home/xxxxxxx/public_html/web/modules/contrib/eca/src/Processor.php(135): Drupal\eca\Entity\EcaStorage->loadByEvent(Object(Drupal\eca_base\Event\CronEvent), 'eca_base.cron')
#7 /home/xxxxxxx/public_html/web/modules/contrib/eca/src/EventSubscriber/EcaBase.php(76): Drupal\eca\Processor->execute(Object(Drupal\eca_base\Event\CronEvent), 'eca_base.cron')
#8 [internal function]: Drupal\eca\EventSubscriber\EcaBase->onEvent(Object(Drupal\eca_base\Event\CronEvent), 'eca_base.cron', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#9 /home/xxxxxxx/public_html/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Drupal\eca_base\Event\CronEvent), 'eca_base.cron', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#10 /home/xxxxxxx/public_html/web/modules/contrib/eca/src/Event/TriggerEvent.php(73): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object(Drupal\eca_base\Event\CronEvent), 'eca_base.cron')
#11 /home/xxxxxxx/public_html/web/modules/contrib/eca/modules/base/src/HookHandler.php(71): Drupal\eca\Event\TriggerEvent->dispatchFromPlugin('eca_base:eca_cr...', Object(Drupal\eca\EcaState), Object(Drupal\Core\Datetime\DateFormatter), Object(Drupal\eca\ConfigurableLoggerChannel))
#12 /home/xxxxxxx/public_html/web/modules/contrib/eca/modules/base/eca_base.module(24): Drupal\eca_base\HookHandler->cron()
#13 /home/xxxxxxx/public_html/web/core/lib/Drupal/Core/Cron.php(335): eca_base_cron()
#14 /home/xxxxxxx/public_html/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(395): Drupal\Core\Cron->Drupal\Core\{closure}(Object(Closure), 'eca_base')
#15 /home/xxxxxxx/public_html/web/modules/contrib/hook_event_dispatcher/src/HookEventDispatcherModuleHandler.php(68): Drupal\Core\Extension\ModuleHandler->invokeAllWith('cron', Object(Closure))
#16 /home/xxxxxxx/public_html/web/core/lib/Drupal/Core/Cron.php(343): Drupal\hook_event_dispatcher\HookEventDispatcherModuleHandler->invokeAllWith('cron', Object(Closure))
#17 /home/xxxxxxx/public_html/web/core/lib/Drupal/Core/Cron.php(159): Drupal\Core\Cron->invokeCronHandlers()
#18 /home/xxxxxxx/public_html/web/core/lib/Drupal/Core/ProxyClass/Cron.php(75): Drupal\Core\Cron->run()
#19 /home/xxxxxxx/public_html/web/core/modules/automated_cron/src/EventSubscriber/AutomatedCron.php(65): Drupal\Core\ProxyClass\Cron->run()
#20 [internal function]: Drupal\automated_cron\EventSubscriber\AutomatedCron->onTerminate(Object(Symfony\Component\HttpKernel\Event\TerminateEvent), 'kernel.terminat...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#21 /home/xxxxxxx/public_html/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\TerminateEvent), 'kernel.terminat...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#22 /home/xxxxxxx/public_html/vendor/symfony/http-kernel/HttpKernel.php(115): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object(Symfony\Component\HttpKernel\Event\TerminateEvent), 'kernel.terminat...')
#23 /home/xxxxxxx/public_html/web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(66): Symfony\Component\HttpKernel\HttpKernel->terminate(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Render\HtmlResponse))
#24 /home/xxxxxxx/public_html/web/core/lib/Drupal/Core/DrupalKernel.php(715): Drupal\Core\StackMiddleware\StackedHttpKernel->terminate(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Render\HtmlResponse))
#25 /home/xxxxxxx/public_html/web/index.php(22): Drupal\Core\DrupalKernel->terminate(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Render\HtmlResponse))
#26 {main}

Further, I get the same error if I try to edit or disable the model via the ECA UI, and when I try to import the model into another copy of the site.

If I export the ECA Model config and import it with "status: false," it changes the status in the config but not in the UI.

I guess that means I have to change the ECA config instead of the ECA Model config, but when I do that I get this rather mysterious error:

Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "private__rDYu60sbWI6g2UEYW4S8VBr9C-73LnNXEJFYjSRvGS8". in Drupal\Component\DependencyInjection\Container->get() (line 159 of core/lib/Drupal/Component/DependencyInjection/Container.php).

The model worked fine in Drupal 10.2.7 and (if I recall correctly) Drupal 10.3.0. It fails only in Drupal 10.3.1.

Just one more note. The cron error was stopping the execution of cron, which meant that none of the cron jobs following ECA cron were running. I worked around this by disabling the ECA cron job. This required installation of Ultimate cron, which permits you to disable a cron job through the UI or (in my case) by exporting and importing the config entry, changing "status" to "false." I'm still not able to disable or edit the ECA model. I may try deleting it via drush later.

Can confirm it's an issue with jobs starting with cron. I'm seeing 📌 Add support for cache collector for state in core Active , which I initially thought might mean it's fixed in 2.0? But this looks like only affects eca_state plugins, which I'm not using in the affected module.

This is causing major issues on one of our sites -- I'll be figuring out a fix shortly (if changes in 2.x didn't fix it already).

freelock → changed the visibility of the branch 3460404-event-eca-cron to hidden.

I guess I've got the same issue while installing a new system, using a profile that installs eca and accompanying configuration. I looked into it and I think I found the cause.

EcaState extends State which extends CacheCollector. As seen in the backtrace in #4, EcaState::getTimestamp() gets called, which invokes State::get(), which invokes CacheCollector::get() which ultimately invokes CacheCollector::lazyLoadCache() where CacheCollector::cache is accessed, but that is null. CacheCollector::cache is set via CacheCollector::__construct, but that is never invoked, since EcaState provides its own constructor, but there just dismisses the cache variable, that gets passed in. This behavior was introduced in commit 53ae52d3287cf5f5b05d644b0e9d118d37d78467 related to issue #3437321.

I'm on Drupal 10.3.1.

I pushed into the issue fork a commit that reverts 53ae52d3287cf5f5b05d644b0e9d118d37d78467. This fixed the problem for me.

freelock → changed the visibility of the branch 3460404-event-eca-cron to active.

Sorry to mess up the branches -- I created two issue branchs, because the first one was against 1.x, not 2.x. So I created the second one.

It looks like @lukas_w added to the 1.x branch -- but it also looks like the same code is present already on 2.x, presumably for 📌 Add support for cache collector for state in core Active .

So I un-hid the branch with the fix, this looks like just be a backport of the other issue.

As correctly described in #10 this is clearly a bug resided within ECA.

It needs test to avoid regression in the future, thus adding the according tag.

I don't think this comment 📌 Add support for cache collector for state in core Active was addressed properly in that other issue. Using a new untested cache layer within the EcaState service may introduce further unwanted side-effects.

Solution path could be to either
1. not extends core's state class and implement back to the original EcaState behavior as it was in 1.1.6 OR
2. extend core state class and overwrite all methods where caching is used to not use caching as it was in 1.1.6 OR
3. add in the new caching layer like core's state service (but for what purpose and benefit?) with proper test coverage by adding the assignment of the cache service passed along to the constructor.

I'd prefer option 1 if that's possible, otherwise option 2.

This breaks a central part of a running Drupal site, thus setting to proper status. If that also breaks installations without using the ECA cron event, this may event be of critical priority. But looks like this is only happening when having a model using that event as described in #4.

Removing myself from assigned -- the site in question is now on 2.x.

Turns out tests are already failing when running tests on 10.3.1. Seems that current CI is configured to test against 10.2, but currently I don't find where that is configured. Gitlab CI testing may need to be adjusted for being tested against 10.3 (latest stable version). Ideally it should test against both 10.2 and 10.3, but most importantly it should test against latest stable core.

MR !438 contains the suggested implementation of #13 option 1.

One error occurred on testing with 10.3. Will have a look.

Occurred error is not related to this issue, but fixed it anyway for not being blocked because of it.

This applies cleanly to ECA 1.17 and Drupal 10.3.1 and appears to fix the problem. It won't run on the live site until Tuesday, but I'll report back if there is a problem then.

Thanks everyone for working on this. I've just merged the fix and will tag a new release 1.1.8 later today.

I'm sure about forward porting this to 2.x, though. I'd rather take advantage of upstream maintenance. The issue here arose due to a BC break in Drupal 10.3, at least in my view. But, as ECA 2 only supports 10.3 or later, we should be save.

Automatically closed - issue fixed for 2 weeks with no activity.