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 → 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