Access token refresh

[equinoxmatt]

Firstly, thank you for the fantastic package. It is executed really well and a pleasure to use.

We are currently integrating the package, but we occasionally have an issue where the token is no longer valid. The package rightly caches the access key, however we don't know if the access key is valid until it is attempted.

To tackle this, we've implemented a workaround outside the package: catching the exception, clearing the cache key, and the package obtains a new access key upon the next request. This approach works, but integrating this functionality directly into the package could be useful.

Would you be open to considering this feature? If so, I'm happy to contribute by submitting a pull request. I wanted to discuss the idea with you before proceeding to ensure it aligns with your vision for the package.

[marcreichel]

Thank you for your kind words, really appreciate it! 🙂

---

Normally, the token get's cached for the token lifetime (coming from Twitch) minus 60 seconds and if the cached token expired a new one is requested on the fly.

So generally speaking there should not be a case where the token for a request actually expires. The emphasis is on "should not" 😅.

I do not doubt you running into that issue. So there might exist such a case for whatever reason.

For the solution I could think of some sort of "retry mechanism". You've mentioned, you're catching the exception, deleting the cached token and wait for the next request. I would take it a step further and retry the current request for n times (if it failed because the token expired) until it succeeds. If all n requests fail, finally throw an exception.

But maybe you meant just that by "next request".

The n should be globally configurable for each request via the package config file, but be overwritable per request as well. Just like the cache_lifetime config + cache method.

Taking these "ideas" into account I'll be happy to accept your pull request 👍🏼🙂