Do not create cache_dir for non-filesystem cache backends (#41157)

[lbajsarowicz]

Description (*)

When every cache frontend is configured with a non-file backend (e.g. 'backend' => 'redis' for both default and page_cache), Magento still creates an empty var/page_cache directory on every cache:flush, setup:upgrade or first request. On deployments where CLI commands run as a deploy user and PHP-FPM as www-data, PHP-FPM then cannot write into that directory and the storefront fails with HTTP 500 before the logger is available.

Root cause. app/etc/di.xml hardcodes backend_options.cache_dir = page_cache for the page_cache frontend, and Pool::_getCacheSettings() intentionally keeps it when merging env.php (#22228). Factory::resolveCacheDir() then calls getDirectoryWrite(VAR_DIR)->create($path) unconditionally — before the backend type is resolved — so the directory is created for a Redis frontend that never uses it.

Fix (minimal, backwards-compatible). Factory::resolveCacheDir() no longer creates the directory; it only resolves the relative cache_dir to an absolute path under var/. The backend that actually uses the path creates it on first use: Symfony FilesystemAdapter::init() does mkdir(..., 0777, true), and SymfonyAdapterProvider::createFilesystemAdapter() already creates the default var/cache. File backends therefore behave exactly as before; Redis/Valkey/Memcached/Database/APCu frontends leave var/ untouched.

This is the smallest change that fixes the report. An alternative that makes the decision explicit in the factory (create the directory only when the resolved backend is file-based, with the check living in SymfonyAdapterProvider) is proposed in the linked PR — maintainers may prefer either; they are mutually exclusive.

Related Pull Requests

• Alternative approach: Create cache_dir only for file-based cache backends (#41157) #41159

Fixed Issues (if relevant)

1. Fixes Magento creates and requires write access to var/cache and var/page_cache even when all cache backends are Redis #41157

Manual testing scenarios (*)

1. Configure app/etc/env.php with 'backend' => 'redis' for both cache.frontend.default and cache.frontend.page_cache (bin/magento setup:config:set --cache-backend=redis --page-cache=redis ...).
2. Remove var/page_cache and var/cache if present.
3. Run bin/magento cache:flush and open any storefront page.
4. Before the fix: an empty var/page_cache directory is created. After the fix: neither var/page_cache nor var/cache exists.
5. Switch page_cache back to 'backend' => 'file', run bin/magento cache:flush and open a storefront page: var/page_cache/<prefix>/... is created and populated as before.

Questions or comments

Only Factory::resolveCacheDir() changes; _getBackendOptions() still creates var/cache for the default file backend and for the local level of remote_synchronized_cache.

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