Argument #1 ($stream) must be of type resource, int given

[Legion112]

I am getting this warning.
Probably problem is part of this PR

Packages:

gregurco/guzzle-bundle-cache-plugin | v3.0.0
guzzlehttp/guzzle | 7.5.0
guzzlehttp/promises | 1.5.2
guzzlehttp/psr7 | 2.4.3
http-interop/http-factory-guzzle | 1.2.0
kevinrob/guzzle-cache-middleware | v4.0.2

[AhmadOf]

I am also having this issue, any fix? thank you

[Legion112]

If your package version greater or equal when mine. Try to clean cache this probably due to serialization error. Or wait a while.

[Legion112]

Probably part of #165

[rahulgupta-acquia]

I am facing same error

Fatal error: Uncaught TypeError: fseek(): Argument #1 ($stream) must be of type resource, int given in /vendor/guzzlehttp/psr7/src/Stream.php:211

did you found any solution?

I am using [guzzle-cache-middleware:4.1.2].

[whoisnobody]

Is there any solution for this problem without clearing the existing cache?

[Legion112]

@whoisnobody wait for a while when cache will expire.

[whoisnobody]

@whoisnobody wait for a while when cache will expire.

I have a very long TTL for the cache and I cannot just clear it. I need to have some middle solution for reading an old cache with the new package. At the moment I hold with v3.5, but I don't want to stuck with this version forever.

[Legion112]

@whoisnobody check out this issue

#165

They offer some solutions

[whoisnobody]

Clearing the cache is not the solution for me.

[Legion112]

@whoisnobody

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

[whoisnobody]

@Legion112 I consider this as a proposition of solution not a ready for use solution. I know that I can implement PSR16 cache class, and also I can implement my own middleware for guzzle and don't use this package. Is that your point?

This package with this changes implemented in v4 is not intended to be safely used when upgraded. It needs extra actions (clearing cache or wait for it to expire). I didn't see any notice about that potential problem from maintainer.
It's especially more dangerous, because more often it may affect production than test or dev environments.

[Legion112]

I agree with you @whoisnobody

Probably this is critical issue @Kevinrob

[dbhynds]

I'd also agree that this is a critical issue. It caused a full site outage in our production environment and led to us missing an uptime SLO.

[Kevinrob]

Does anyone want to suggest a fix in the form of a PR to this problem?
I don't have much time in the next few weeks to watch this.

[Legion112]

I would propose serialization via symfony serializer

But I am not sure how to handle existing issues with different versions of class
Need some try catching logic