We’re seeing a lot of INVALID_GRANT errors on production (never in sandbox) in an inconsistent manner.
I have seen e1775’s post here but I think ours is slightly different.
Our platform is making most requests fine up until around “peak” hours, i.e friday/staturday night, when sometimes we’ll see INVALID_GRANT errors happen for a few minutes or just randomly, everything will be fine for a while until it starts again.
We’ve also used the Symfony cache to store tokens, as it’s PSR-6 compliant as per the specifications of your PHP bundle - https://github.com/symfony/cache
Few questions:
Have you had any infrastructure issues/changes recently around token storage?
What status code and message are thrown for hitting our rate limit? I’ve not seen this documented anywhere, if this is a 401 it could be triggering your PHP bundle to attempt to refresh tokens.
Are there any other circumstances besides INVALID_GRANT that can trigger a 401 response?
Any suggestions or issues you can see with our setup above?
No, there were no changes recently on how tokens are generated and stored
It’s a 429 status code response
Not really. Would be interesting to check the error body, if it says that the token is “revoked” it’s very highly likely that it’s because the token is missing on our replicas.
Which version of the PHP library are you using? The latest one should minimize by quite a lot the number of errors.
On the other hand, this week we have launched a new MySQL balancer that will dramatically reduce these issues. Could you check on your side if this weekend, compared with the previous the errors have reduced?
I believe we’re on version 3.6.3 of the bundle, according to our composer.lock
The message we’ve always got is “the access token is invalid”, I can look at dumping/logging the full body for this is there’s more info outside of the message component of the response (i.e in the data array). Do INVALID_GRANT errors also populate that data array?
Unfortunately I can’t replicate this locally properly so haven’t been able to handle it fully yet.
We’ve only just rolled out our implementation so we don’t have any data on last weekend I’m afraid, however it’s been pretty bad this weekend for it, any orders we’ve had through our app have logged errors when polling for info.
That’s strange. A token can potentially return a 401 during its first 1-2 seconds of its lifetime, as it might not be available in the replicas. But after having a valid token, you should not have any issue at all, as they expire after 1 month of being issued.
Feel free to contact us through direct message so that we can investigate further.
I’ve created our own version of your Authenticator to get around the issue, I’ll be making a ticket in the repo tomorrow to request some changes to make this easier (mostly changing private methods to protected) as right now I can’t extend that class.
This is probably something that’ll need doing anyway, as our use case is multiple Stuart accounts on one system, which the PHP bundles Authenticator doesn’t support right now (as the cache key is based on just the URL we’re using, doesn’t take into account any client ids for caching multiple access keys).
Apologies for this, didn’t realise the cache bundle was incompatible without the extension above. I was getting fairly confused too as I only expected to get on of these per month.