fix: token refresh retry offline + recover on visible

[thorwebdev]

What kind of change does this PR introduce?

In combination with supabase/auth#466 this PR should resolve the most critical token refresh issues,

• Fixes Token refresh fails silently when offline and never recovers #226
• Fixes supabase.js/gotrue.js token refresh does not work on mobile devices going in and out of "sleep" mode. supabase#6464
• Maybe Fixes Token refresh time is likely set too "short" if less than 60 seconds left before it expires. #272

cc @GaryAustin1

[GaryAustin1]

Edit:
It is not clear to me why you can not just call for a new refresh token if within EXPIRY_MARGIN+1 (+1 to not have to deal with fixing rounding and margin issues discussed below) and either way set the timer to expiresIn- EXPIRY_MARGIN. I think other changes require a minimum token expire length > EXPIRY_MARGIN by at least a few seconds to be useful, so the reason for the .5 (which was token life of less than 60 seconds) goes away.
::

I have an open issue that addresses in the first part .5 seconds as not enough time to complete refresh.
#272

I have a trace showing failure to do preflight and refresh request within 500msec in that issue (even though who ever came up with it felt it was enough time)

So if it is possible for the time left to expiration is EXPIRY_MARGIN + .5 or 1 or less, the token could expire for a brief amount of time if code can run and use the token before this task is finished (which I have not traced thru entirely).

I also think the rounding error mentioned in that issue still exists here and by cutting it so close with the .5 as Date.now() could get rounded up adding up .5 seconds you don't have if on the margin.

[thorwebdev]

We've made the following decisions:

1. We will default JWT expiry to 15mins in the future (once we've verified all the token refresh issues have been resolved)
2. We will allow a minimum JWT expiry of 30s.
3. We will default the expiry margin to 10s.
4. In case of network failure we will retry every second.

So if you set JWT to the smallest possible value (30s), the client library will refresh it every 20s.

[inian]

Since we are throwing even if result.ok is false, lets have a generic message like "Request Failed"? Cos this will get triggered both for network errors and server errors like timeouts etc

[inian]

a counter and stop pinging gotrue or stop pinging after expiry time is reached cos gotrue is not going to refresh that token anyway

[thorwebdev]

Added exponential backoff, starting with 200ms and then exponentially backing off for 10 retries

[github-actions]

🎉 This PR is included in version 1.22.14 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀

[GaryAustin1]

@thorwebdev I can confirm the new supabase.js 1.35.3 refreshes the token when coming back from sleep in my test suite from supabase/supabase#6464

I do notice one issue though so far. My test code has a visibility handler to generate a select when tab goes visible. That fails with JWT expired. I put a delay of 5 seconds in to the select and it works. I put a delay of 100msec in and it did not work (still get JWT expired)

So at a minimum anyone using a visibility handler needs to check for token refreshed before executing an SB RLS call.

Worse case is though that ANY CODE THAT RUNS before the refresh finishes will error.

I will try and work on a test for this not using a visibility handler in my code, but I am starting a 10 day road trip in the morning, so may not be able to get to it quickly.

Select is in doStuff.

        if (document.visibilityState === "visible" ) {
            //await checkSession()
        setTimeout(function(){ doStuff(); }, 100);
       }

[GaryAustin1]

@thorwebdev If there is a better place for me to document findings on this pull request let me know.

I've not been able to figure out how to test the issue above without a visibility handler yet.

The following trace bothers me, and although I guess not a bug is certainly different in how gotrue.js will run.
I expected the new code to not do anything if the token was not within expire time, but it generates a signin event on every hidden to visible transition, which on a desktop tab could be 100's of times while the app is in use in an hour. On the desktop the refresh also normally occurs in background, so you should never have a stale token. Why even issue a signIn in event in the visibility handler, if token is good to go? Note: the visibility handler messaged below is mine, not gotrue's, but occur on same event.