Use current sore id for category runtime cache

[ilnytskyi]

Description (*)

This is shorter PR version of https://github.com/magento/magento2/pull/34226/files that only fixes main issue and does not include suggested performance improvements.

When emulation is used or custom code saves the category in different stores, the object stored in runtime might be from wrong store to that causes data override.

Related Pull Requests

Fixed Issues (if relevant)

1. https://github.com/magento/magento2/issues/22063
2. https://github.com/magento/magento2/issues/32478

Manual testing scenarios (*)

1. ...
2. ...

Questions or comments

Contribution checklist (*)

• [ ] Pull request has a meaningful description of its purpose
• [ ] All commits are accompanied by meaningful commit messages
• [ ] All new or changed code is covered with unit/integration tests (if applicable)
• [ ] README.md files for modified modules are updated and included in the pull request if any README.md predefined sections require an update
• [ ] All automated tests passed successfully (all builds are green)

[m2-assistant[bot]]

Hi @ilnytskyi. Thank you for your contribution Here are some useful tips how you can test your changes using Magento test environment. Add the comment under your pull request to deploy test or vanilla Magento instance:

• @magento give me test instance - deploy test instance based on PR changes
• @magento give me 2.4-develop instance - deploy vanilla Magento instance

:exclamation: Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s) For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names. Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE,
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

You can find more information about the builds here

:information_source: Run only required test builds during development. Run all test builds before sending your pull request for review.

For more details, review the Magento Contributor Guide documentation.

:warning: According to the Magento Contribution requirements, all Pull Requests 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 Pull Requests 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.

:pencil2: Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel

[ilnytskyi]

@magento run all tests

[magento-automated-testing[bot]]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time.

[ilnytskyi]

@magento run all tests

[magento-automated-testing[bot]]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time.

[ilnytskyi]

@magento run all tests

[magento-automated-testing[bot]]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time.

[ilnytskyi]

@magento run all tests

[magento-automated-testing[bot]]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time.

[ilnytskyi]

@magento run all tests

[magento-automated-testing[bot]]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please message the #magento-devops slack channel if they don't show in a reasonable amount of time and a representative will look into any issues.

[engcom-Hotel]

@magento run all tests

[engcom-Hotel]

@magento run Unit Tests, Integration Tests, Functional Tests B2B

[ilnytskyi]

@engcom-Hotel I think they can be ported from https://github.com/magento/magento2/pull/34226 or that PR can be processed instead

[engcom-Hotel]

Hello @ilnytskyi,

As I can see, the https://github.com/magento/magento2/pull/34226 PR has some performance improvements along with the fix for the main issue. But I can see the same failures on that PR as well.

And also this PR has been Community Picked so as per the process we need to process it, and we need a green build for the same. So I request you to please do the needful for this PR.

Thanks

[engcom-Dash]

@magento run all tests

[engcom-Dash]

@magento run Integration Tests

[engcom-Dash]

@magento run all tests

[engcom-Dash]

@magento run all tests

[engcom-Dash]

@magento run all tests

[engcom-Dash]

@magento run Static Tests, Integration Tests, Functional Tests B2B

[engcom-Dash]

@magento run all tests

[engcom-Hotel]

@magento run Functional Tests B2B, Functional Tests EE, Integration Tests

[engcom-Dash]

Hello @ilnytskyi,

Thanks for your contributions!

I tried to replicate the issue by following the steps outlined in the issue, but it did not work. While I have reviewed the changes and they look good to me, could you please provide some manual testing steps to help reproduce the issue?

Thanks again!

[ilnytskyi]

@engcom-Dash They are covered in new tests from my extended PR: https://github.com/magento/magento2/pull/34226/files#diff-0c57d86ecc634a08c2d329ff07f105f94a34b55d7945804b31740fc21cd4c781

And described in description: https://github.com/magento/magento2/pull/34226

basically previously when custom code did something with category in multistore loop and did not provided store key to category repo. It was cached under all key. It could cause random data override including url generation. My change should fix it, as instead of taking random data from all key we take it form provided or currently emulated store

I think that Magento/CatalogUrlRewrite/Observer/CategoryUrlPathAutogeneratorObserverTest.php test might be failing due to not cleared runtime cache for category repository. As I see it was added before my changes, and might be affected by the original issue.

Maybe

$this->categoryRepository = $this->objectManager->create(CategoryRepositoryInterface::class);

Should be used to isolate tests or removing shared instances in tearDown. I am not sure if AppIsolation works correctly.

[engcom-Dash]

Hello @ilnytskyi,

Thank you for your contributions!

✔️ QA Passed

I appreciate your efforts in addressing the issue. While it was challenging to replicate the original problem, I created a script for debugging. I found that when fetching the same category without specifying a store, the functionality was fetching data from the array key 'all', leading to potential conflicts.

After your changes, I can confirm that the system now creates distinct store IDs as keys in the array. This ensures that the correct category data is retrieved for each store, even when a store ID is not specified.

Builds are failed, hence moving it to Extended Testing.

[engcom-Dash]

@magento run Integration Tests

[engcom-Dash]

@magento run all tests

[engcom-Dash]

@magento run Unit Tests, Functional Tests B2B

[engcom-Dash]

Got a green build so I'm moving it to 'Merge in Progress.'