Problem/Motivation
#3486503 added $this->reset() to CacheCollector::destruct(). Drupal\Core\Utility\ThemeRegistry extends CacheCollector, and Registry::destruct() destructs every runtime registry but keeps returning the same objects from getRuntime(). After the reset their storage is empty, and ThemeRegistry::has() and get() read it without reloading.
As a result, anything rendered in the same process after theme.registry is destructed gets "Theme hook X not found" (field, links, time, ...) and the renderer outputs bare text. We hit it with Search API index_directly during drush cron: search_api.post_request_indexing is destructed after theme.registry and renders the entities saved during cron, so the indexed HTML has no templates. It only happens when the runtime registry was already used earlier in the same process. Seen on 11.4.6 and 11.4.8.
Steps to reproduce
$registry = \Drupal::service('theme.registry');
$registry->getRuntime()->has('container'); // TRUE
$registry->destruct();
$registry->getRuntime()->has('container'); // FALSE
Proposed resolution
In Registry::destruct(), empty ry after destructing the collectors, so
a later getRuntime() builds a fhe cache again.
Remaining tasks
Review.
User interface changes
None.
API changes
None.
Data model changes
None.
Issue fork drupal-3626982
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:
Comments
Comment #3
luxx91 commentedThe merge request is ready for review. The test-only job fails on the new test as expected, and the pipeline is green.
Comment #4
nicxvan commentedThis is a duplicate of: #3626105: Release runtime theme registries after destruction
I'm going to close this in favor of that one since it's already RTBC thanks!
Comment #5
nicxvan commented