Empty Rules are firing

Unfortunately, the commit in this issue is the cause of #3106316: Scheduler Rules integration - failures at Core 8.7 - Rules cache update problem. I'm not saying that Rules is at fault, and I have not yet found any solution, either as a fix to Scheduler Rules Integration or to Rules code. However, moving the line $results[$event_id] = RulesComponent::create($action_set); inside the conditional on if ($configs) has caused the problem. If that single line is moved back out of the conditional block, all works fine and nodes which satisfy Scheduler condtions can be editted OK.

It seems that the actual problem is one of how the cache gets updated. In the failure cases we get

Drupal\Core\Entity\EntityStorageException
SQLSTATE[21S01]: Insert value list does not match column list:
1136 Column count doesn't match value count at row 1:
INSERT INTO {cache_rules} (cid, expire, created, tags, checksum, data, serialized) VALUES () ON DUPLICATE KEY UPDATE cid = VALUES(cid), expire = VALUES(expire), created = VALUES(created), tags = VALUES(tags), checksum = VALUES(checksum), data = VALUES(data), serialized = VALUES(serialized); Array()
in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 847 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php

which looks like empty data is being passed to the SQL query. So I looked at the backtrace

Drupal\Core\Database\Query\Upsert->execute() (Line: 263)
Drupal\Core\Cache\DatabaseBackend->doSetMultiple(Array) (Line: 193)
Drupal\Core\Cache\DatabaseBackend->setMultiple(Array) (Line: 112)
Drupal\rules\Engine\RulesComponentRepository->getMultiple(Array, 'rules_event') (Line: 140)

and in RulesComponentRepository::getMultiple() we have conditional logic on $cids_missing. It is that final call to $this->cacheBackend->setMultiple($cache_items) which causes the error.

Here is the source code for Scheduler Rules Integration.

Because it works OK in 8.8 and 8.9 maybe the SQL backend layer is doing something differently? I am stumped as to how to proceed with this, so any suggestions will be very welcome.

Thanks for the feedback, really helpful, and confirming that it is a Rules problem has encouraged me to investigate further. I think I have solved the problem and can also explain why it works OK in 8.8 and 8.9 but fails in 8.7

In my manual testing I have created one reaction rule, event is on saving existing content, and not filtered by content type.

After clearing the cache there is always at least one new entry in $cache_items in RulesComponentRepository::getMultiple so calling cacheBackend->setMultiple($cache_items) will always be OK. With the old code before this commit to only fire rules where a $config exists, on executing the rule a second time without clearing the cache, the executed component is retrieved from cache and the "missing" $cid is got from resolvers[$provider]->getMultiple (EventComponentResolver.php::getMultiple in this case) which would always return something, so there was always values in $cache_items which meant that cacheBackend->setMultiple($cache_items) would run OK.

Now, with the new code in EventComponentResolver.php::getMultiple to only store results where there are $configs, we do not get back anything for the item which is not already in the cache. $resolved_results is empty, which means $cache_items is empty and cacheBackend->setMultiple($cache_items) fails. In case I have not explained the above very clearly I have uploaded a pdf with output debug and annotations.

I think the solution is that in RulesComponentRepository::getMultiple() we only call cacheBackend->setMultiple if $cache_items is not empty. Or alternatively wrap the whole section with a conditional on $resolved_results not being empty. I have attached a patch for this.

The reason it does not fail in core 8.8 and 8.9 is that DatabaseBackend::doSetMultiple() now has a check to exit early if $values is empty, but this is not in the 8.7 code.

For info, I don't think it was related to #3104328: Move list builders from D8RE into Rules as that commit was 13th January but I found the fault on 10th.

I have created #3108494: Exception when updating cache with empty data
Setting this issue back to Fixed.