Problem/Motivation
Placeholder:
When multiple caches are stacked max-age is not calculated correctly. When something uses the max-age of a lower cache the max-age is just reused, even if this is way later than the earlier cache. This can result in broken, invalid cached especially in situations where cache might be purged that is inside the stack of cached objects.
Some related isssues:
#3444257: ResourceObjectNormalizer::getNormalization can result in max-age drift when different sets of fields are requested
#2449749: Add #cache['downstream-ttl'] to force expiration after a certain time and fix #cache['max-age'] logic by adding #cache['age']
#2443073: Add #cache[max-age] to disable caching and bubble the max-age
Steps to reproduce
Proposed resolution
Option 1:
When creating a new cache entry based on others, substract (expires - timestamp) from the max-age.
Option 2:
When talking with casey, there was another idea. What if (for non render arrays) we hook into serialize and unserialize and update max-age there. Consider this story:
"Im a cache, and I know how long I need to live before I die. I go to sleep, then i don't feel time continuing. When i wake up, i should make sure to update my clock to the correct time". This could be a way to fix it rather globally and have the serializer handle the time changes for max age. Feels pretty focussed, but might not really fir the responsibilities.
Option 3:
What if we set max-age and expires both when set. Which would mean calculating expires from max-age as it is set, and setting max age based on the time() versus expires being set.
Remaining tasks
- Write failing unit test
- Update code that uses
$this->variationCache->get
and always returns cacheable objects. - Profit
User interface changes
n.a.
API changes
n.a.
Data model changes
n.a.