I bumped into a weird entity cache invalidation issue in one of my module's test.
After my test updates a user it seems the user storage does not get invalidated automatically - only in tests, I could not reproduce this problem by executing the same actions in the UI. I think this problem is a side-effect of \Drupal::service() vs. $this->container usage in tests.
When I saw my test had started to fail then I automatically added $this->container->get('entity_type.manager')->getStorage('user')->resetCache(); call to my test to ensure user cache is empty before my test loads the user with user_load_by_mail(). Even after this forced cache clear my test still failed so I started to go deeper in code and then I realized the memory cache inside $this->container->get('entity_type.manager')->getStorage('user) is not the same as in \Drupal::service('entity_type.manager')->getStorage('user') . So basically I cleared an already empty memory cache and user_load_by_email() used a completely different storage/memory cache which has not been cleared yet.
I think when a user entity gets updated Drupal automatically invalidates the related cache entries, but what if in tests it runs the invalidation in an incorrect user storage? Or I do not know what else could explain why I have to call \Drupal::service('entity_type.manager')->getStorage('user')->resetCache(); manually.

cache invalidation issue

Fun fact, the test that required this fix runs the user synchronization in the UI. There is an another test which runs the synchronization with Drush and that test does not require this fix.

CommentFileSizeAuthor
entity_storage_cache_invalidation_in_tests.png309.14 KBmxr576

Comments

mxr576 created an issue. See original summary.

mxr576’s picture

mxr576
Primary language Hungarian
Location Hungary
commented
Issue tags: +\Drupal is an anti-pattern

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev
mxr576’s picture

mxr576
Primary language Hungarian
Location Hungary
commented
Version: 9.3.x-dev » 10.0.x-dev
Issue tags: +Needs issue summary update

My colleague also reminded me that services (like access control handlers) with their own internal cache also works unexpectedly in kernel tests too. For example, due to access control handler's static cache property you either force-flush the cache every time when it should have been invalidated or do things like:

    $this->enableModules(['FOOO']);
    // We need the updated user access handler with our access alters
    // registered.
    $this->accessHandler = $this->container->get('entity_type.manager')->getAccessControlHandler('user');
catch’s picture

catch
he/him
Primary language English
commented
Status: Active » Closed (duplicate)

This is the same issue as #2066993: Use magic methods to sync container property to \Drupal::getContainer in functional tests. $this->container can be state after a request against the tested site, but \Drupal gets refreshed. We haven't been able to figure out a way to keep $this->container fully in sync, so the recommendation is to use \Drupal everywhere, except that issue isn't finished yet.

catch’s picture

catch
he/him
Primary language English
commented
Issue tags: +Bug Smash Initiative