Cache Race condition

[PeterNone]

Hi

I use your Client with a cache like described here:

https://github.com/googleapis/google-api-php-client#caching

I got problems with this implementation:

My application makes 2 calls at the same time and I got an error:

{
    "statusCode": 500,
    "error": {
        "type": "SERVER_ERROR",
        "description": "ERROR: unlink(\/home\/<server_name>\/domains\/<domain>\/app\/..\/cache\/federated_signon_certs_v3): No such file or directory on line 26a in file \/home\/<server_name>\/domains\/<domain>\/vendor\/league\/flysystem\/src\/Adapter\/Local.php."
    }
}

So the first request is deleting the file before it got the content and the second one comes in and it throws this error.

The Google Auth keys are updated every 24h. There is a specific header telling when they will expire but the file is updated every 2h or so anyway. So the headers are ignored and it uses some default refresh value. If you know what should I add to this setup to use the headers expiry date so the first request after the expiry date will trigger the update of cache would be great.

So my question is: Can you provide other recommended implementation of cache that will not create a cache file before it expires at liest? Code examples would be great cause I'm not a backend developer.

It would be also nice to be prepared to not hit race condition cause I got answers like this on this issue:

https://github.com/thephpleague/flysystem/issues/1279#issuecomment-786482608

Which is not comforting at all.

Thanks for your help

Regards Peter

[peterkimga]

Hi, any update on this one?

[PeterNone]

Hi.

There will be some answer to this topic or not realy?

Cause I would like to code something on top of this? I know I do not have a premium support but it's almost 3 weeks now.

Regards Peter

[PeterNone]

Hi So, it's 4 weeks now. And no answer or interest in this issue.

Can you at least replay to it where this help can be found? If your not interested in replaying for it.

Regards Peter

[bshaffer]

Since we do not maintain a caching library, the simple answer here would be to use a PSR-6 complaint caching library which does prevent race conditions (as there's nothing we can do in this library to prevent a race condition in a dependent library).

As to your request to be smarter about when to bust the cache (depending on the cache control), that is definitely something we can look into. This wouldn't prevent the race condition, but it would at least make a collision less likely due to the cache refreshing less frequently.