[lbajsarowicz]

Description (*)

Magento\Deploy\Model\Plugin\ConfigChangeDetector::beforeDispatch() runs on every request that reaches the front controller (frontend, adminhtml, GraphQL, REST). Each run calls ChangeDetector::hasChanges(), which loads the stored config_hash flag from the flag table. In practice the stored hashes almost never change between requests, but the query runs every time.

The plugin now caches a successful check in the config cache type. The cache key is derived from the freshly generated hashes of the importer sections. If config.php or env.php is edited, the generated hashes change, the key misses, and the existing database comparison runs and throws as before. Hash::regenerate() (run by app:config:import and setup:upgrade) cleans the cached entries after it saves new hashes. Without that, a sequence of "A in sync → import B → restore A without import" would still hit A's old entry. The clean runs after the flag is saved, outside the existing try block, so a cache backend error is not reported as "The hash isn't saved."

ChangeDetector itself is unchanged, so CLI commands (app:config:status, app:config:import, config:set --lock-*) compare against the database exactly as before. DbStatusValidator, the sibling beforeDispatch check, already caches its result the same way (db_is_up_to_date).

Measured on a clean 2.4-develop install: every uncached request (page, GraphQL, REST, admin) loses one SELECT flag.* FROM flag WHERE flag_code='config_hash' once the cache is warm.

Related Pull Requests

Fixed Issues (if relevant)

1. Fixes ConfigChangeDetector loads the config_hash flag from the database on every uncached request #41731

Manual testing scenarios (*)

1. Enable the MySQL general log, request an uncached page twice (for example /customer/account/login/) and a GraphQL storeConfig query.
2. Before: each request runs SELECT flag.* FROM flag WHERE flag_code='config_hash'. After: only the first request after a cache clean runs it.
3. Change a value in the system section of app/etc/config.php without running app:config:import: the next request throws "The configuration file has changed. Run the "app:config:import" or the "setup:upgrade" command to synchronize the configuration."
4. Run bin/magento app:config:import; requests work again. Restore the previous config.php without importing: the next request throws again.

Questions or comments

Both new constructor arguments are optional, with an ObjectManager fallback. With deployment/blue_green/enabled the plugin returns early, as before.

The cached entry lives until the next config cache clean or Hash::regenerate(). Multi-node installs need a shared cache backend for the regenerate clean to reach every node, which Magento already requires for the config cache. A stored hash changed directly in the database (for example a DB restore) is noticed after the next cache flush.

Tests: unit tests for the plugin (warm cache skips Hash::get(), in-sync result cached, changed configuration not cached and still throws, blue/green bypass) and for Hash (clean after a successful save, no clean when the save fails). New integration test Magento\Deploy\Model\Plugin\ConfigChangeDetectorTest with the real config cache: no flag select on a warm request, and the A → B → A sequence throws. Locally: unit, PHPStan, the static (LiveCodeTest) suite and the integration test pass; the warm-cache integration test fails without the plugin change.

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