TypeError Phpfastcache\Drivers\Files\Driver::driverRead(): Return value must be of type ?array, bool returned about phpfastcache HOT 13 CLOSED

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

from phpfastcache.

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.

from phpfastcache.

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).

from phpfastcache.

Hello curious contributor !
Since it seems to be your first contribution, make sure that you've been:

• Reading and searching out our WIKI
• Reading and agreed with our Code Of Conduct
• Reading and understood our Coding Guideline
• Reading our README
  If everything looks unclear to you, tell us what 😄
  The Phpfastcache Team

from phpfastcache.

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...

from phpfastcache.

Georges what about allowing people to choose between two methods in driver config

• serialize
• json_encode
  ?

from phpfastcache.

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.

from phpfastcache.

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 :)

from phpfastcache.

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?

from phpfastcache.

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.

from phpfastcache.

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 :/

from phpfastcache.

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.

from phpfastcache.

Will be implemented as of v9.2.

from phpfastcache.