Resolve legacy cache backend class names to their Symfony adapters (#41213) - #41236

Description

2.4.9 routes cache creation through Symfony Cache. Magento\Framework\App\Cache\Frontend\Factory::createSymfonyCache() passes the raw configured cache/frontend/*/backend string to SymfonyAdapterProvider::createAdapter(), and that provider resolves the value against $adapterTypeMap, which contained short aliases only (redis, valkey, memcached, libmemcached, file, database, apc, apcu, two_levels, twolevel). Both createAdapter() and createTagAdapter() end with $resolvedType = $this->adapterTypeMap[$backendTypeLower] ?? 'filesystem';, so a backend configured with a class name — Magento\Framework\Cache\Backend\Redis, ...\Valkey, ...\Database, ...\Memcached, or the legacy Cm_Cache_Backend_Redis — never matched and resolved to a FilesystemAdapter.

Class names remain a supported configuration surface: Factory::_getBackendOptions() accepts any class_exists() backend in its default: case, Factory::isSymfonyL2Cache() already normalises a lowercased FQCN alongside its short aliases, and the class-name form is what the Redis page cache documentation shows. The result on an upgraded store is a cache that reports healthy from cache:status and the admin while every entry goes to var/cache and Redis stays empty.

This change adds the lowercased class names to the existing map, next to the aliases they correspond to. Both call sites read the same map, so no new resolution logic is introduced.

Not included, deliberately: turning the ?? 'filesystem' default into an exception, and logging when the fallback is taken. Both are worth doing, but they are a behaviour decision rather than a bug fix — throwing would break installations running a custom backend class, and constructing a logger at cache bootstrap is circular with the cache itself. Happy to follow up in a separate PR if maintainers want the fallback to fail loudly or warn.

Eaccelerator, MongoDb, RemoteSynchronizedCache, SymfonyL2Cache and AbstractBackend are intentionally left unmapped: they have no equivalent adapter in this map, and SymfonyL2Cache is already handled by Factory::isSymfonyL2Cache().

Note for whoever sequences this: #41159 also touches SymfonyAdapterProvider.php (it adds resolveAdapterType()/isFilesystemBackend() helpers around the same fallback for the unrelated cache_dir fix in #41157). The two changes are compatible but will conflict textually.

Fixed Issues

Fixes #41213

Manual testing scenarios

1. Install 2.4-develop with Redis reachable over TCP.
2. Configure app/etc/env.php with the class-name form:

   'cache' => ['frontend' => ['default' => [
       'id_prefix' => 'magento2_',
       'backend' => 'Magento\\Framework\\Cache\\Backend\\Redis',
       'backend_options' => ['server' => '127.0.0.1', 'port' => '6379', 'database' => '1'],
   ]]],

3. Run bin/magento cache:flush, browse a storefront page.
4. Before: redis-cli -n 1 dbsize stays 0 and var/cache grows. After: cache entries appear in Redis db 1 and var/cache stays empty, matching the behaviour of 'backend' => 'redis' with identical backend_options.

Questions or comments

Gates run locally against upstream/2.4-develop: unit (11 tests, 15 assertions — the new SymfonyAdapterProviderTest), PHPCS (0 errors, 0 warnings on both files), PHPStan (no errors), static/LiveCodeTest (green; 2 skips reproduce on a clean checkout). The unit tests avoid live services — Redis via an unconnected \Redis instance, Memcached via the extension_loaded() failure Symfony raises before touching a socket, Database via a mocked ResourceConnection — and two of them pin the unchanged filesystem default for an unmapped backend type.

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)
• All automated tests passed successfully (all builds are green)