Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multistore Issue. One response for all stores. #3

Open
AleksLi opened this issue May 10, 2018 · 1 comment
Open

Multistore Issue. One response for all stores. #3

AleksLi opened this issue May 10, 2018 · 1 comment
Assignees
Labels

Comments

@AleksLi
Copy link

AleksLi commented May 10, 2018

Preconditions

  1. Magento 2.2.3
  2. mysql Ver 15.1 Distrib 10.0.31-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
  3. PHP 7.0.22

Steps to Reproduce

  1. Install this module (obviously)
  2. Multistore.

Expected Result

  1. Cached response for each store separetely

Actual Result

  1. I've got one result for each store.

One comment about this situation.

I've fixed that issue by adding new key into

<type name="MSP\APIEnhancer\Api\CacheManagementInterface">
        <arguments>
            <!--
            This set of keys is for non-Varnish keys configuration
            It should be based on request information only
            -->
            <argument name="keys" xsi:type="array">
                <item name="store" xsi:type="object">MyCompany\WebApi\Model\CacheKeyProcessor\Store</item>
            </argument>
        </arguments>
    </type>

MyCompany\WebApi\Model\CacheKeyProcessor\Store returns new key with store Id.

@phoenix128 phoenix128 self-assigned this May 13, 2018
@phoenix128 phoenix128 added the bug label May 13, 2018
@bvboas
Copy link

bvboas commented Nov 21, 2018

Isn't the store code part of the URI

[rest/default/V1/products/:sku]

and with that a different key is generated?

I can't reproduce this issue...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants