[ousamabenyounes]

Q	A
Branch?	3.x
Bug fix?	no
New feature?	yes
BC breaks?	yes
Deprecations?	no
Fixed tickets	Fix #1624
License	MIT
Doc	yes

This adds an optional cache service ID to Flysystem resolver configuration. When configured, the factory keeps the Flysystem resolver as the inner service and exposes a PSR-6-cached resolver under the configured resolver name, matching the existing cache-decoration pattern used by the S3 resolver.

The Flysystem resolver documentation and 3.x changelog now describe the option.

Test verification (RED → GREEN)

On unmodified origin/3.x with the new functional configuration and regression test:

ERRORS!
Tests: 1, Assertions: 0, Errors: 1.
Unrecognized option "cache" under
"liip_imagine.resolvers.cached_flysystem.flysystem".

With the implementation:

OK (1 test, 2 assertions)

Full local replay compared with origin/3.x:

baseline: OK (941 tests, 2387 assertions)
final:    OK (943 tests, 2401 assertions)
PHP-CS-Fixer: identical 29-file pre-existing baseline
PHPStan: identical 13-error pre-existing baseline
changed-line coverage: PASS 14/14

[dbu]

does wrapping the psr cache resolver around the flysystem resolver not work? https://symfony.com/bundles/LiipImagineBundle/current/cache-resolver/psr_cache.html - the example wraps an S3 resolver, but if i am not mistaken, you can wrap any resolver with the cache resolver

[ousamabenyounes]

Yes—the PR reuses PsrCacheResolver around FlysystemResolver. It adds a cache option to the Flysystem factory so this wrapping can be configured without a separate service definition; it doesn't add a new caching implementation.

[dbu]

thanks for the explanation.
as the cache resolver is a generic concept, i don't like that the configuration in this pull request is specific to one resolver. if we want to add something that saves the user the effort of defining their own service, i think it should be a generic solution to cache any resolver.

[dbu]

do we need all these suddenly?