Multi-store cache conflict with Varnish

[br33f]

Preconditions and environment

Magento 2.4.3-p2 and 2.4.6 for sure. Perhaps other versions too.

1. There must be at least two store views configured.
2. Multi-store must be set up on a single domain (using cookie)
3. Full Page Cache > Caching application should be set to Varnish.
4. Varnish configuration is set according to the configuration generated with "Export VCL for Varnish 6"

Steps to reproduce

1. Enter a page (let's call it X) that is available on both store views (and URL is the same)
2. Switch store to non-default (let's call it B)
3. Clear all cache (including Varnish)
4. Go to Developer tools and delete "X-Magento-Vary" cookie. Leave other cookies (store etc.) as it is.
5. Refresh page
6. Try to switch back to default store view (let's call it A)

Expected result

Store view switches back to default store view. The page shows content from store view A (default).

Actual result

You can not switch store view back to default store view on the page you visited. It works fine on another pages. However this particular page X is being returned from Varnish which (because the lack of X-Magento-Vary cookie) cached store B contents as default (A) (without X-Magento-Vary cookie).

Even if you switch store view to default on another page and then navigate to Page X - store switcher will show invalid store and page content is still wrong.

Additional information

Varnish stores cache according to X-Magento-Vary cookie. If this cookie is missing - Varnish assumes that it is a default store view. However one can make a request without X-Magento-Vary cookie, but still with "store" cookie. Magento does not validate that, it returns content for specified "store" - but Varnish caches it without X-Magento-Vary.

Then if you visit page with default store view (X-Magento-Vary cookie not present) - Varnish serves you with invalid store view page.

Release note

No response

Triage and priority

• [ ] Severity: S0 - Affects critical data or functionality and leaves users without workaround.
• [X] Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
• [ ] Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
• [ ] Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
• [ ] Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.

[m2-assistant[bot]]

Hi @br33f. Thank you for your report. To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, Add a comment to the issue:

• @magento give me 2.4-develop instance - upcoming 2.4.x release
• For more details, review the Magento Contributor Assistant documentation.
• Add a comment to assign the issue: @magento I am working on this
• To learn more about issue processing workflow, refer to the Code Contributions.

---

Join Magento Community Engineering Slack and ask your questions in #github channel. :warning: According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting. :clock10: You can find the schedule on the Magento Community Calendar page. :telephone_receiver: The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.

[br33f]

I don't think it is reproducible on the Magento instance that the m2-deployment-service provides. I don't know if it is possible to configure Varnish properly on that instance - the default is Built-in cache.

[m2-assistant[bot]]

Hi @engcom-Bravo. Thank you for working on this issue. In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

• [ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
• [ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue.
• [ ] 3. Add Area: XXXXX label to the ticket, indicating the functional areas it may be related to.
• [ ] 4. Verify that the issue is reproducible on 2.4-develop branch
  Details

  - Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!
• [ ] 5. Add label Issue: Confirmed once verification is complete.
• [ ] 6. Make sure that automatic system confirms that report has been added to the backlog.

[andreifurrnica]

@magento give me 2.4.6-p3 instance

[andreifurrnica]

@magento give me 2.4.6-p3 instance

[magento-deployment-service[bot]]

Hi @andreifurrnica. Thank you for your request. I'm working on Magento instance for you.

[magento-deployment-service[bot]]

Hi @andreifurrnica, unfortunately there is no ability to deploy Magento instance at the moment. Please try again later.

[engcom-Bravo]

@magento give me 2.4-develop instance

[magento-deployment-service[bot]]

Hi @engcom-Bravo. Thank you for your request. I'm working on Magento instance for you.

[magento-deployment-service[bot]]

Hi @engcom-Bravo, here is your Magento Instance: https://6efece40340867e82008d6084f3d96b7.instances-prod.magento-community.engineering Admin access: https://6efece40340867e82008d6084f3d96b7.instances-prod.magento-community.engineering/admin_8988 Login: 436de28a Password: 8476c48fb821

[engcom-Bravo]

Hi @br33f,

Thank you for reporting and collaboration.

Verified the issue on Magento 2.4-develop instance and the issue is reproducible.Kindly refer the screenshots.

Steps to reproduce

• Enter a page (let's call it X) that is available on both store views (and URL is the same)
• Switch store to non-default (let's call it B)
• Clear all cache (including Varnish)
• Go to Developer tools and delete "X-Magento-Vary" cookie. Leave other cookies (store etc.) as it is.
• Refresh page
• Try to switch back to default store view (let's call it A)

We are not able to switch to default store view.

Hence Confirming the issue.

Thanks.

[github-jira-sync-bot]

:white_check_mark: Jira issue https://jira.corp.adobe.com/browse/AC-11545 is successfully created for this GitHub issue.

[m2-assistant[bot]]

:white_check_mark: Confirmed by @engcom-Bravo. Thank you for verifying the issue.
Issue Available: @engcom-Bravo, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.

[ln8711]

Seem like function getCurrentStoreId from vendor/magento/module-store/Model/StoreResolver.php doesn't get correct store code at this part:

$storeCode = $this->request->getParam(
            \Magento\Store\Model\StoreManagerInterface::PARAM_NAME,
            $this->storeCookieManager->getStoreCodeFromCookie()
 );

so the result is it returns the default store instead.

I had to add some code after that to detect the store view using HTTP_HOST value by comparing it with all stores base url (except admin store) to return correct store code after the line above.