[Question]: Why is the upper bounds of refreshTokenRetryInSeconds tied to tokenRefreshInSeconds?

[Tre665]

What Version of the library are you using? ^12.0.3

Question Hello, we are using the auth code flow with refresh tokens and wanted to test out, how our App behaves on slow internet connections.

And there we observed, that with our previous settings that either the call to the token endpoint times out or the one to the jwks endpoint. Or to be more specific: The lib seems to made a new call every 3s, which seems not enough time to complete both requests on slow connections and it ends up in a never ending looping of failed retries.

We looked at the docs and we found the settings refreshTokenRetryInSeconds and silentRenewTimeoutInSeconds. These options seems to be intended for our use case. So we set both values to a reasonable time (although the default setting for silentRenewTimeoutInSeconds should be well enough with 20s)

Unfortunately that didn't change anything. It still tried to refetch every 3s and doesn't wait for the other calls to succeed.

We had a closer look in the docs and found that the limit of refreshTokenRetryInSeconds is bound to the value that is set on tokenRefreshInSeconds (which defaults to 3s). And in fact, when we changed this value to 10s it was enough time for our tests on slow connections.

However, the drawback with setting tokenRefreshInSeconds to a higher value is that it also means, that the check of the of the token validity would be delayed which might lead to other issues (for example dropped internet connection, awaken from sleep etc.). And if we are not totally off the silentRenewTimeoutInSeconds value is never considered, when the tokenRefreshInSeconds is set to a lower limit?

So ideally we would keep this tokenRefreshInSeconds to a lower limit (like the default with 3s). And our question is if there is a specific reason why the tokenRefreshInSeconds sets the upper bounds for refreshTokenRetryInSeconds and implicitly for silentRenewTimeoutInSeconds (calls will be also canceled as soon as tokenRefreshInSeconds emits).

Or maybe we just oversee something here :D

Thanks in advance!