-
-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Access token not refreshed for realtime channels after being offline or in standby #274
Comments
I can confirm that I'm experiencing this also. |
Could you look into this? 👋 @w3b6x9 |
Is anyone else experiencing obscenely long cookies (such as using Keycloak as an auth provider)? I am noticing 2 or more cookies for a single login, causing a ton of errors and seemingly this one too. I documented it here supabase/supabase-js#963 but does anyone else experiencing this issue specifically (realtime refresh failing) also have multiple auth cookies? |
Thıs needs to be resolved asap. |
This is still broken. Here's a simpler version of the temporary workaround that seems to work ok. Essentially, what is does is watch the channel for a "Access token has expired" response, sends a "auth.refreshSession()" request, then discards the open channel and creates a new one. I've created a module - e.g. supabase-realtime-bug.ts
and then I can reuse it
Looking forward to a fix for this! |
@create-signal are you seeing this with supabase-js? if so which version? I also think there's some element on supabase-js where we're not properly setting the token back and at first we thought it could be a supabase-js version specifically |
I'm testing with supabase-js version 2.45.4 The issue occurs when the auth module stops refreshing the access token because the device is asleep or idle. When the device resumes the asynchronous "refreshSession" method runs and the socket sends an "access_token" message simultaneously (with the old access token). So the logs will look like this:
An easy way to test this without putting your computer to sleep is to
|
perfect!!! thank you for reporting this and a potential fix 🙏 I will check with the remainder of the team as this can also be the source of another issue we're seeing where it seems realtime just tries to connect with expired tokens. |
Just FYI, i think the It looks like the backend server sends an 'error' and a 'phx_close' event for each open channel when the access token expires, which then triggers RealtimeChannel to remove itself from RealtimeClient.channels[] (L175 of RealtimeChannel.ts) Using RealtimeClient.setAuth() (like supabase-js does) after the channel is removed from that array won't have any effect, when ideally it would be able to assign the new access token to the channel and "rejoin()" |
@create-signal are you able to reliable replicate this error? if so could you provide a small repo or a gist with the code to do so? I've been trying to replicate it with no success 😓 |
facing a similar issue right now, users appear offline after token expires if they are inactive or in a different tab/window. |
Bug report
When a user is offline or in standby mode, the access_token is not refreshed as it requires a POST request to auth/v1/token?grant_type=refresh_token (which obviously fails without a connection). When the user comes back online or is active again, Supabase doesn't automatically refetch the access_token and supply it to realtime channels. Instead, the realtime channels error and show the following message, because they try to connect with the old token:
Even if the access_token is refreshed afterwards, the channels don't seem to pick up the change. The only way to get the channels to work again is by removing and re-initializing them.
To Reproduce
The realtime channel tries to reconnect with the old token (because Supabase wasn't able to refetch it without a connection) and errors out. It doesn't pick up any new tokens once Supabase refreshes them again in the usual interval.
Expected behavior
If any realtime channels are still active after re-enabling WIFI or disabling standby, Supabase should refetch the access_token right away and supply it to the channels. This way, they won't error out.
System information
Additional context
I've built a temporary workaround to the fix the issue, maybe it can help:
The text was updated successfully, but these errors were encountered: