Closed Jankyz closed 8 months ago
Hello curious contributor ! Since it seems to be your first contribution, make sure that you've been:
Hello,
That's weird, unserialize only returns false
upon invalid string passed through.
I'll take a look, but you are may facing corrupted stored cache files.
Cheers,Georges
it looks like Phpfastcache can serialize objects and save them (no errors), but it has a problem when we want to get the same objects and unserialize them...
Georges what about allowing people to choose between two methods in driver config
Georges what about allowing people to choose between two methods in driver config
* serialize * json_encode ?
Because unlike unserialize, json_decode does not allow de-serializing object with custom class names.
Just ran into this myself. It was indeed a corrupted cache file in my situation. Any reason why you are not handling this? The decode function could be returning null if the unserialize function returns false
In case the passed string is not unserializeable, false is returned and E_NOTICE is issued.
Just ran into this myself. It was indeed a corrupted cache file in my situation. Any reason why you are not handling this? The decode function could be returning null if the unserialize function returns
false
In case the passed string is not unserializeable, false is returned and E_NOTICE is issued.
I'm not handling this case because if it happens it is a server issue rather than a Phpfastcache issue. So if a corrupted cache occurs the idea is to let you know be aware that there's an issue somewhere. No to handle it silently like nothing happened :)
I'm not handling this case because if it happens it is a server issue rather than a Phpfastcache issue. So if a corrupted cache occurs the idea is to let you know be aware that there's an issue somewhere. No to handle it silently like nothing happened :)
I understand, but you typehinted your functions, thus you are creating a coding issue. If you want this problem to be handled upstream, why not throw an exception?
I understand, but you typehinted your functions, thus you are creating a coding issue. If you want this problem to be handled upstream, why not throw an exception?
I'm not creating a coding issue, your server is causing coding issue by storing corrupted files expecting Phpfastcache to silently handle the issue and get over it. If an exception is thrown or a PHP error appears, the result is still the same: An error somewhere in your application prevent Phpfastcache from running smoothly. Badly unserialize is one of the functions that should've thrown on invalid (like json_decode does now), but it still doesn't and return scalar on error instead of throwing exception.
So until now I felt no necessity to catch this kind of error because it is very rare and outside of Phpfastcache scope, at least in your case. 9.2 is coming in 2024, I'll add an exception on this block of code, but again, it is not a coding issue, just a server issue.
I'm not creating a coding issue
If your return types do not match, it is a coding issue. (mismatch between driverRead
and decode
return types)
If an exception is thrown or a PHP error appears, the result is still the same
With an exception i can determine upstream if it is a cache contents issue. A php coding error should not be used to identify this.
An error somewhere in your application
Corruption can happen for many reasons. In my experience it is almost never an application or phpfastcache issue, but just some weird stuff happening on disk.
The biggest problem i have is that i can not 'repair' the corrupted data, as the code crashes on a PHP issue. With an exception thrown i might be able to catch and delete the cache contents (hopefully that will not trigger the same issue).
For now I consider that issue as an exclusive server-side issue. I can make a better error handling if you'd like so, but it is a low priority until next month since the 9.2 will be shipped with some new features, driver updates and internal performances improvements.
That block of code never thrown any errors until now even in the worst conditions with huge stress tests configured on the CI :/
I can make a better error handling if you'd like so
That would be nice.
That block of code never thrown any errors until now even in the worst conditions with huge stress tests configured on the CI :/
I think (for now) it is just a coïncidence it happend. We are using phpfastcache multiple years without any issue related to corrupted cache contents, so there is no need to rush anything now.
Will be implemented as of v9.2.
What type of issue is this?
Exception/Error/Warning/Notice/Deprecation
Operating system + version
Linux 5.10.198-187.748.amzn2.x86_64
PHP version
8.0.26
Connector/Database version (if applicable)
No response
Phpfastcache version
9.1.3 ✅
Describe the issue you're facing
I'm being swamped with errors of this kind
TypeError Phpfastcache\Drivers\Files\Driver::driverRead(): Return value must be of type ?array, bool returned
I use
Files
as a driver I think that this method has a problem with return from thisinside we have
return $value ? \unserialize($value, ['allowed_classes' => true]) : null;
and when data cannot be unserialized then the function returns
false
example of invalid serialized object
$content = 'a:1:{s:5:"Test";s:15:"serialize here!";}';
Expected behavior
return should be
array|null