Why do I need to do manual refresh of the realtime token?

[jbojcic1]

I am using custom auth with Supabase by using the accessToken method (see accessToken under options here). The code looks something like this:

export const myDb = createClient<Database>(supabaseUrl, supabaseAnonKey, {
  accessToken: () => {
      console.log('accessToken method called');
      return supabaseSessionStore.getState().getJwtWithRefresh();
  },
  db: {
    schema: 'myschema',
  },
});

My getJwtWithRefresh makes sure to refresh the token before it expires. In logs I see accessToken method called being logged every 5 or so seconds and everything works fine.

However the issue is with supabase realtime. When the token expires and is refreshed, the realtime doesn't seem to be updated and it seems that I need to manually call supabase.realtime.setAuth('fresh-token') after each refresh as described here. Why is that so? Couldn't Supabase handle that internally by detecting when accessToken method returns a new token and then call realtime.setAuth internally?

[GaryAustin1]

You should probably consider a feature request as that is the way it is currently.

[jbojcic1]

@GaryAustin1 ok, thx. I updated the category of this discussion to feature request. Is that enough or new one should be created?

[GaryAustin1]

That is basically the same as creating one as it is just a category. I have no inside knowledge to how effective the process is or how often they look at them. The other approach is to raise an issue in the appropriate repository, in this case realtime-js probably.

[jbojcic1]

After looking more into this, heartbeat is calling setAuth which ends up calling accessToken method but I think that in my case the problem is that after the app has been in a background for a bit the heartbeat stops so refreshed token is not set.

[jbojcic1]

I always stop my realtime when tab is not visible on first error (or 3 minutes in but not critical). Then restart on visible and check for missed data.

Interesting. Why do you that? Isn't supabase-js supposed to have automatic reconnection? Is it because automatic reconnection is buggy (from my experience it mostly works but then sometimes it doesn't)?

In my case I am not worried about the missed updates while connection was not alive because when app comes to foreground again I just pull the latest data. My main issue is that connection sometimes just doesn't get re-established and I am trying to figure out why and how to solve that

[GaryAustin1]

I've seen it lose connection in background. Plus I don't want it to auto connect and me not know as it would have missed any changes during the re-connection process.

[jbojcic1]

and me not know as it would have missed any changes during the re-connection process.

I solved that by doing data pull when status of the subcription goes back to subscribed

still auto reconnection doesn't seem like something 100% reliable so I might need to do what you did

[GaryAustin1]

Here are two studies I did way back. This was before webworkers.

https://github.com/GaryAustin1/Realtime2
https://github.com/orgs/supabase/discussions/5641

I've never messed with setAuth as I just use supabase auth.
You could also look thru the issues in realtime and realtime-js for more discussions on it particular the one on web workers.

[GaryAustin1]

Note you need to do it on a system status of postgres_changes connecting which is 100's of msec to seconds after SUBSCRIBED status.

Also I'm going to the new broadcast send from a trigger function so I have a table with all changes I can reload by last time received from, and not deal with postgres_changes replication and lag.