[MGNLADVCACHE-102] Pages with component variants breaking cache Created: 11/Jul/18  Updated: 26/Jul/18  Resolved: 25/Jul/18

Status: Closed
Project: Advanced Cache
Component/s: personalization
Affects Version/s: None
Fix Version/s: 1.9.1, 2.0.1

Type: Bug Priority: Critical
Reporter: Roman Kovařík Assignee: Roman Kovařík
Resolution: Fixed Votes: 0
Labels: caching, personalization-integration
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Screen Shot 2018-07-25 at 07.16.04.png    
Issue Links:
dependency
depends upon MGNLPN-426 Pages with component variants breaki... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Release notes required:
Yes
Date of First Response:
Epic Link: Support
Sprint: Basel 150, Kromeriz 155
Story Points: 8

 Description   

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.

Problem explanation:

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:

info.magnolia.personalization.variant.PersonalizedDescendantsVisitor

    @Override
    public void visit(Node node) throws RepositoryException {
        if (variantManager.hasVariant(node)) {
            personalizedDescendants.add(node);
        }
    }

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


 Comments   
Comment by Milan Divilek [ 25/Jul/18 ]

Reopen: This needs backport to 1.9.x. Version 1.9.x should be used in M5.6.x, because we shouldn't update module in bundle to new major version and because using version 2.0 in both (5.6 and 5.7) cause migration issue (see )

Generated at Sun Feb 11 23:11:02 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.