Repository navigation
Storing PHP serialized data in caches MUST be avoided #165
Description
I was bitten by this several times already.
You have a running application in production heavily relying on cached data.
You upgrade a PHP dependency like going from 3.5.0 to 4.0.1, everything is working as expected during tests.
You confidently push code to production.
Everything breaks in production, and you have a hard time figuring why. You revert the changes and the issue does not stop until you somehow manage to either clear all caches (if your infrastructure can support it) or wait for the cache TTL.
What happened: stored data is incompatible between the 2 versions. Some properties have changed in CacheEntry v3.5.0...v4.0.1#diff-cc5ac6f8871a586dc5f99a175c4e7d9a9f9093c11638546b5b7d176daa28a271
Already cached data contains a messageBody property which is then unused by new code.
PHP unserialization does not tell you anything but created objects are in invalid state.
For this reason, I encourage to avoid storing anything other than string in caches and handle serialization elsewhere.
At the moment, I have a custom PSR16 cache implementation to avoid the issue. I think having something handling serialization of CacheEntry as raw_string or at least, normalized data (stdClass, array or scalar values) which is immune to this issue
Activity
EricTendian commentedon Jul 17, 2022
I encountered this issue as well when doing the dependency upgrade. I did some digging and it seems like #156 is the culprit. The release notes should probably be updated to note this breaking change more prominently (and how the fix is to clear the cache).
seanhamlin commentedon Dec 20, 2022
I also encountered this issue, took ages to find the root cause. Clearing out the cache solved the issue for me too.
Kevinrob commentedon Mar 8, 2026
I believe that PR #216 (which addresses #172) will also resolve the most critical impact of the issues described here.
While PR #216 doesn't change the underlying storage format yet, it introduces a robust failsafe and validation mechanism during the unserialize process of CacheEntry. Now, if a cached entry is found to be incompatible or corrupted (e.g., following a library or Guzzle update), the library will strictly invalidate it and trigger a clean Cache MISS instead of crashing the application or serving inconsistent data.