Problem/Motivation

We already reset quite a few things when doing POST requests, like statically cached config. We didn't do it for entities because we didn't have an API for that for a long time.

Doing this should remove the need for a lot of manual cache clear calls.

Proposed resolution

Reset the static entity cache service.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

CommentFileSizeAuthor
#14 3040878-14.patch13.48 KBranjith_kumar_k_u
#9 3040878-9.patch13.67 KBraman.b
#7 entity-static-cache-reset-3040878-7-interdiff.txt681 bytesberdir
#7 entity-static-cache-reset-3040878-7.patch13.68 KBberdir
#2 entity-static-cache-reset-3040878-2.patch13 KBberdir

Issue fork drupal-3040878

Command icon 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:

About issue forks

Comments

Berdir created an issue. See original summary.

berdir’s picture

berdir
Primary language German
Location Switzerland
commented
Status: Active » Needs review
StatusFileSize
new entity-static-cache-reset-3040878-2.patch13 KB

Added that and as a test, removed most resetCache() calls in node.module tests. Did run one locally and it still passed.

Status: Needs review » Needs work

The last submitted patch, 2: entity-static-cache-reset-3040878-2.patch, failed testing. View results

hchonov’s picture

hchonov
Primary language Bulgarian
Location Burgas
commented 
+++ b/core/lib/Drupal/Core/Test/RefreshVariablesTrait.php
@@ -33,6 +33,7 @@ protected function refreshVariables() {
+    \Drupal::service('entity.memory_cache')->deleteAll();

+1 on the solution, we actually even use it.

I haven't thought on proposing this to core, because it does not cover the case, where the static cache service is exchanged in the storage. It might be better to provide a new method on the entity storage - resetStaticCache() and iterate over the entity storages and call the method on each of them.

However I am also fine with the current approach, because the probability for the case I've mentioned is very little :).

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

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). 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.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now 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.

berdir’s picture

berdir
Primary language German
Location Switzerland
commented
Status: Needs work » Needs review
StatusFileSize
new entity-static-cache-reset-3040878-7.patch13.68 KB
new entity-static-cache-reset-3040878-7-interdiff.txt681 bytes

Reroll and fixing the failing test. That assert is the wrong way round, assertGreaterThan() is pretty confusing as it tests that the second argument is larger than the first, so it's kind of reversed than what you'd think. That's also consistent with the previous assert above, which is also "reversed". This was copied and not updated because it passed due to the static cache.

Status: Needs review » Needs work

The last submitted patch, 7: entity-static-cache-reset-3040878-7.patch, failed testing. View results

raman.b’s picture

raman.b commented
Status: Needs work » Needs review
StatusFileSize
new 3040878-9.patch13.67 KB

Required another re-roll after 3159230.

Also, the failed test from #7 is passing locally, so moving back to Needs review

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

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

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

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

ranjith_kumar_k_u’s picture

ranjith_kumar_k_u commented
StatusFileSize
new 3040878-14.patch13.48 KB

Rerolled #9

Status: Needs review » Needs work

The last submitted patch, 14: 3040878-14.patch, failed testing. View results

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

berdir opened merge request !10075

berdir’s picture

berdir
Primary language German
Location Switzerland
commented
Status: Needs work » Needs review

Beside removing a lot of complexity (when and when not to reset cache) and lines of code, it also uncovers bugs and incorrect assumptions in tests when we forget to reset the cache.

For example https://git.drupalcode.org/project/drupal/-/merge_requests/10075/diffs?c.... That test never actually tested what I thought it did, because it was always testing against the original stale entity.

smustgrave made their first commit to this issue’s fork.

smustgrave’s picture

smustgrave commented
Status: Needs review » Reviewed & tested by the community
Issue tags: +Needs Review Queue Initiative

1) Drupal\Tests\block\Functional\BlockCacheTest::testCachePermissions
Behat\Mink\Exception\ResponseTextException: The text "smx906fw" was not
found anywhere in the text of the current page.

Appears to be random but since 100+ commits back now I did a simple rebase to make sure.

I wasn't 100% sure if we should have a CR but since it's just around tests I didn't think it would be needed.

Edit

Rebase was good and green.

Change LGTM

bradjones1’s picture

bradjones1
Primary language English
commented

I'm not sure if there is a policy that speaks to this but a CR would be good as this is a pretty important change to the base test setup and is not obvious.

smustgrave’s picture

smustgrave commented
Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs change record

Lets do it!

berdir’s picture

berdir
Primary language German
Location Switzerland
commented
Status: Needs work » Needs review

Created https://www.drupal.org/node/3491185.

This is mostly a DX thing when writing new tests and shouldn't affect any existing tests, except those that implicitly or explicitly rely on the current static cache behavior, like the one example in core that I had to fix.

For new tests, it should now mostly just work without having to think about internal entity features.

Note: I have not verified if every single resetCache() call in core is still needed, but I removed enough to show that this works I think and quite a few are still necessary as their changes are not done by form submissions.

smustgrave’s picture

smustgrave commented
Status: Needs review » Reviewed & tested by the community
Issue tags: -Needs change record

CR reads well too me. So restoring previous status.

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

Rebased and removed an unused variable that is now reported on by phpcs, no other changes.

  • catch committed c1c78fd1 on 11.x 
    Issue #3040878 by berdir, smustgrave, hchonov: Reset static entity cache...

catch closed merge request !10075

catch’s picture

catch
he/him
Primary language English
commented
Status: Reviewed & tested by the community » Fixed

Looks great! Committed/pushed to 11.x, thanks!

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

🤩

Developers around the globe thank you!

Status: Fixed » Closed (fixed)

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