Affects Version/s: None
Release notes required:Yes
Sprint:Basel 150, Kromeriz 155
Magnolia Release:5.6.8, 5.7.1
I've encountered a rather serious bug in the personalization cache that breaks pages with component variants.
This problem can also be reliably reproduced on demoauthor/demopublic.
The issue occurs after clearing the cache / on a request that triggers a 'store' behaviour in the cache. If this first request serves a page with an active component variant, the cache breaks and stores the personalized page as an InMemoryCachedEntry instead of an PersonalizedCacheEntry. This causes the cache to always serve the same personalized page no matter the traits.
The code in question:
The check hasVariant(node) will fail on the component node with the variant since the node is already wrapped with the variant meaning the node itself is already the variant. Extending the check to if (variantManager.hasVariant(node) || variantManager.isVariant(node)) will solve the issue (I don't know if this might cause side effects. Maybe the check needs to be extended further) and create a correct cache entry.
Steps to reproduce:
- Create a component variant on a page with different content and add a trait to it (something simple like tourType cookie)
- Publish the page including the variants
- Visit the page on public and create a tourType cookie with any value via dev tools (so the variant should be served)
- Log into public admincentral and clear cache and log out (important because of authenticated cache policy)
- Reload the page (cookie still active). This will cause to load the page with the active component variant and cache it
- Delete the cookie
- Reload page
--> You will still get the page with the active component variant although the trait isn't active