[lbajsarowicz]

Description (*)

Magento\Store\App\Config\Type\Scopes::get() keeps the scopes data (websites, store groups, store views) only in an instance property. The first call of every request reads its source, scopesConfigSourceAggregated, whose RuntimeConfigSource runs SELECT * on store_website, store_group and store. The first caller is StoreManager::getStore() while Http::launch() builds the session config, before the built-in full page cache is checked. So every storefront, GraphQL and REST request and every built-in FPC hit pays three queries. app:config:dump scopes does not help: the aggregated source still reads the runtime DB source.

Scopes now stores the aggregated data in the config cache type, serialized with the core serializer and tagged store, store_group and website.

• Warm requests read it from the cache.
• Nothing is cached when the database is not available (deployment on a separate build machine, setup), or when the runtime source returned no rows from any of the three tables. This keeps the case that commit 2633933 (MAGETWO-56989) removed the original cache for.
• Invalidation uses the paths that already exist. StoreManager::reinitStores() cleans the config cache by store_relations, store, website and store_group after store save, group save/delete and website create/delete. Store delete cleans the config cache. AbstractModel::cleanModelCache() cleans the entity tag on every save. cache:clean config and cache:flush remove the entry too.
• Scopes::clean() still resets only the in-memory data. App\Config::clean() runs on every admin config save and on application-server reload, and must not drop the shared entry.

RuntimeConfigSource gets two small public methods, isDbAvailable() and hasRuntimeData(). It also implements ResetAfterRequestInterface, as Scopes now does.

Measured on a clean 2.4-develop install with warm caches, before the change: a built-in FPC hit ran 4 queries, 3 of them these selects; /customer/account/login/ ran 10, with the same 3. With the change, the integration test shows a fresh Scopes instance on a warm cache running no queries.

Related Pull Requests

Fixed Issues (if relevant)

1. Fixes Scopes config type is not cached: store, store_website and store_group are selected on every storefront request, including built-in FPC hits #41730

Manual testing scenarios (*)

1. Warm the caches, enable the MySQL general log, request / twice (built-in FPC HIT) and /customer/account/login/.
2. Before: each request runs SELECT store_website.*, SELECT store_group.* and SELECT store.*. After: none of them on warm requests.
3. Create a store view in the admin, then open the storefront store switcher: the new store view is available without any manual cache clean.
4. Rename a store group, update a website name, delete the store view: each change shows up on the next request.
5. bin/magento cache:clean config: the next request reads the three tables once and caches them again.

Questions or comments

All new constructor arguments are optional, with an ObjectManager fallback. No di.xml change.

Store, group and website changes written with raw SQL (for example in a data patch) are not seen until the next config cache clean. setup:upgrade and setup:install clean caches. This matches the other store data already kept in the config cache (StoreManager's stores data).

Tests: unit tests for Scopes (cache hit and miss, tags, no-DB bypass, no caching without runtime data, memory-only clean()) and RuntimeConfigSource. New integration test Magento\Store\App\Config\Type\ScopesTest: a fresh Scopes instance with a warm cache runs zero queries; store view save/delete, store group rename, existing website update and config cache clean each invalidate the cached entry. Locally: unit, PHPStan, the static (LiveCodeTest) suite and the integration test pass.

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]

Hi @lbajsarowicz. Thank you for your contribution!
Here are some useful tips on how you can test your changes using Magento test environment.
❗ 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
ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

---

For more details, review the Code Contributions documentation.
Join Magento Community Engineering Slack and ask your questions in #github channel.

[lbajsarowicz]

@magento run all tests