Possible BC break in `CacheItemPoolDecorator` since 2.10.2
Closed this issue · 2 comments
As per laminas/laminas-cache-storage-adapter-apcu#7 (comment) I think this is a BC Break, take a look at:
Missing keys shouldn't result in a return false here.
Originally posted by @Slamdunk in #85 (comment)
TL;DR: null is never returned by any of the underlying cache backends. This means, that the comparison of CacheItemPoolDecorator is just useless and thus it returns true in any case, no matter if the keys were deleted or not.
Imho, that is a problem of the underlying storage.
StorageInterface::removeItems is clear on this:
I've recently found the same problem in laminas-cache-storage-adapter-redis.
The thing is, that it only worked due to the fact that the CacheItemPoolDecorator tested for an impossible return type. So actually, true was returned in any case. Even tho, deletion was not successful due to a cache backend error, e.g.
I am uncertain on how we should handle this, as there are adapters which actually do return an empty array.
What we could do is to pre-filter all keys, which do not exist. After that, we only pass those keys to deleteItems which might exist. This may ensure that the underlying storage does not return keys for those items which never existed in the first place.
This is how the SimpleCacheDecorator implemented that.
Released 2.10.3 and 2.11.1 with a fix.