Stacked caches result in max-age drift in caches

bbrala → credited acbramley → .

bbrala → credited casey → .

bbrala → credited enyug → .

bbrala → credited larowlan → .

bbrala → credited mstrelan → .

bbrala → credited nick_schuch → .

Adding credits to people who investigated this, casey as colleague and people from 🐛 ResourceObjectNormalizer::getNormalization can result in max-age drift when different sets of fields are requested Active .

Quick patch that synchronizes the max age of cached date with the current time if the cached item has an expire set.

Opened a MR against 11.x with the patch.

Adjusted logic to max-age properly, jsonapi tests are now green again.

The unittest failure makes sense since we need to return a RefinableCalculatedPermissions in some cases to adjust max-age. Need to zoom into that if we need it, or when this could happen.

core/tests/Drupal/FunctionalTests/Installer/InstallerTranslationExistingFileTest.php
That one is a little weird. Why is 403's, dunno. Could be related to the changes in the AccessPolicy.

Yey, another caching issue where we can collaborate @bbrala! ;)

I guess the patch is irrelevant anymore, the latest state in the MR.

Let's start with a rebase.

If you could review the child for jsonapi that would be awesome, then we can 0erhaps start with precedence.

This issue will get blocked on the same stuff as https://www.drupal.org/project/drupal/issues/2352009 🐛 [pp-3] Bubbling of elements' max-age to the page's headers and the page cache Postponed i think. Some parts of core do not use max age properly which would mean Lots of breakage in cacheability and that will break sites as catch mentions in that issue.

Even though caching is broken sometimes right now :x

If you could review the child for jsonapi that would be awesome,

JSONAPI tests... again... noooo :) on it

🐛 ResourceObjectNormalizer::getNormalization can result in max-age drift when different sets of fields are requested Active has landed :D

Wow! Found this thanks to 🐛 ResourceObjectNormalizer::getNormalization can result in max-age drift when different sets of fields are requested Active .

Looks like the entire "D8 cacheability" effort back in 2013–2015 overlooked this general problem! 😬

Hehe yeah, let's make exceptional caching into super exceptional caching haha

We are running into this issue, specifically with the render cache causing an incorrect max age to be bubbled in the following scenario:

1. The Dynamic Page Cache is enabled.
2. A node page is loaded which has a max age set so that it expires in, e.g., 1 hour.
3. The response in the Dynamic Page Cache is evicted/expired/invalidated while the render cache for the node is still valid.
4. The node page is loaded again, and the render cache is used, causing the cache item's original max age to be bubbled up to DPC.
5. The DPC now serves a stale version of the node page for some time after the render cache item's intended expiration.

Adjusting the max age of the render cache item as done in the MR seems to resolve the issue, allowing the DPC to cache responses for the appropriate amount of time.

It may be worthwhile discussing whether to split the access policy processor fix into its own issue; it doesn't necessarily meet the requirements for a "Major" issue in my opinion, so it probably shouldn't hold up progress on the other fixes in this issue.