Supabase Realtime React Native silently fails when loading session from storage and using RLS/JWT

[Kavanaugh Latiolais]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

Supabase Realtime React Native silently fails when loading session from storage and using RLS that relies on supabase JWT claims.
Subscribing to postgres changes reports ok be receives no updates if the session is loaded from storage. Logging out and back in resolves the issue.

SUBSCRIBED and CLOSED events occur as expected. Logging realtime events at info show the same events in either case with the exception of the expected.

Disabling RLS immediately fixes the issue and reenabling immediately re-triggers it.
RLS policy is checking a property on the JWT so this appears to be the issue.
Setting the Realtime auth token manually via

supabase.auth.onAuthStateChange((event, session) => {
  if(session) {
    supabase.realtime.setAuth(session?.access_token);
  }
});

resolves the issue.

Expected behavior

Sessions loaded from storage or newly logged in should be able to use properties of the supabase jwt without manually setting.

Additional context

This is a regression as at some point previously this workaround was not required with the same RLS polices

Auth options are

{
   autoRefreshToken: true,
    persistSession: true,
    storage: AsyncStorage,
}

Versions:

    "@react-native-async-storage/async-storage": "1.22.3",
    "@supabase/supabase-js": "2.39.8",

[Filipe Cabaço]

Could you open a support ticket so we can analyse this issue in more detail?

[Kavanaugh Latiolais]

Ticket ID is 2538336802

[Daniel Montgomery]

Hello, is there any progress on this issue yet?
It seems like there's a related issue as well with no resolution posted yet:
#254

On Supabase.com I'm able to impersonate my authenticated user with the inspector and listen to events with no problem. On localhost, it appears to think my authenticated user is still anonymous despite non-realtime data loading without issue. Only changing the RLS policy makes realtime functional on localhost.

[anngbaum]

oof just spent a bunch of time debugging this as well – support ticket 2879712393 is a one-sided journey to the exact same conclusion.

I believe the issue was caused by #273 – in my testing, the problem is that the accessToken gets set as the apiKey when the realtime client is initialized, and apiKey is the anonymous supabaseKey per here. as mentioned above, it only fixes itself on login or token refresh.

we were able to implement with the workaround, but seems like a good thing to fix!