Realtime not reconnecting after going offline and refreshing app in Expo

[jmeistrich]

Bug report

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

Describe the bug

In an Expo app in development mode with an iOS simulator, going offline and back online and then reloading the app results in realtime being stuck in errors even through reloads until the app is force quit.

This may be in development-only, but not sure because it blocked releasing to production. We've had multiple reports of a bug in Legend State (LegendApp/legend-state#362) which track back to this root problem.

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

This was reproduced by multiple people starting from the Expo with-legend-state-supabase example, but it may happen in any Expo project.

Add this code to log the error:

supabase
    .channel(`LS_TEST`)
    .on(
        'postgres_changes',
        {
            event: '*',
            table: 'todos',
            schema: 'public',
        },
        (payload) => {
            console.log('payload', payload);
        },
    )
    .subscribe((status, error) => {
        console.log('status', status);
        console.log('error', error);
    });

1. Quit app if already open
2. Open app, realtime connects
3. Go offline and back online
4. Reload app in dev tools
5. Realtime errors forever even with more reloads, until app is fully restarted with this log:

status CHANNEL_ERROR
error undefined

Expected behavior

Realtime should work after reload

System information

• OS: macOS
• Browser (if applies): Expo with iOS simulator
• Version of supabase-js: 2.45.1
• Version of Node.js:20

[Saad-Bashar]

Would be great if we can fix this! Legend state with supabase is such a great combo to build offline first app!

[pedrio-gh]

Any news on this? It is really useful and the rest of the integration works flawlessly

[haeniya]

Hi everyone, we're facing the same issue.

I created a minimal repro that you can check out here:
https://github.com/haeniya/supabase-realtime-repro
There's also instructions on how to reproduce the issue.

After some investigation, it seems to be related to RLS policies. Without any policies on the table, the real-time channels are working fine. As soon as I add two standard policies for INSERT and SELECT, the issue comes up.

Unfortunately, this is currently affecting our productive chat app and makes real-time channels and therefore our app unusable.

It would be great to get some feedback on this.
Many thanks.

[filipecabaco]

Awesome @haeniya ! I will check this soon as I also need to tackle another Expo issue: #415 (comment)

From your Expo experience, is there some sort of Web Worker like API for Expo? This could be related with another issue we're tackling where we will need to change the way we fetch authorization tokens 🤔 #439

[haeniya]

Thanks @filipecabaco.

There's the TaskManager (https://docs.expo.dev/versions/latest/sdk/background-fetch/) or the BackgroundFetch library (https://docs.expo.dev/versions/latest/sdk/background-fetch/) that could be worth checking out.

[filipecabaco]

Task Manager seems to be the way to go if we want to build something generic with low dependencies. Do you know of any lib that supports this in an hybrid manner?

Aka as Web Workers or Task Manager depending on the runtime

[haeniya]

@filipecabaco I don't know of any library that does that, unfortunately.

Just for my understanding, could you elaborate a bit on what you think is causing the issue? Is it because the Web Workers API is used in Supabase, but isn't available in the Expo / React Native runtime?

I did some more research, maybe also the React Native's Interaction Manager could help: https://reactnative.dev/docs/interactionmanager.html

And I found another library that does something similar: https://github.com/margelo/react-native-worklets-core

But not sure what's the best way of making this generic for all the runtimes. Could you maybe fallback to something else, if Web Workers are not available?

[filipecabaco]

I think that there are currently two problems:

• Realtime on start is not setting the proper authentication token which we're currently tackling in feat: Implement token callback; fix CI testing #439
• We might require a background job to run the heart beat and keep the connection alive

The first one, as mentioned, I think it's the biggest issue so that's why that is the priority now but the second one could also be extremely useful to avoid constant reconnect and also allow apps to be kept alive (e.g. heartbeat every 30s to keep conn alive). For that we would need something similar to Web Workers.

To do that we do the effort of keeping realtime-js compatible with multiple runtimes or we fork realtime-js to have a realtime-expo for example and leave that configurable in supabase-js 🤔 but for that decision it would be useful to know what other developers have done in the past in scenarios like this.

[haeniya]

Thanks for clarifying @filipecabaco.

Regarding the second problem, depending on the complexity of this, maybe it could be feasible to have a default implementation but also make it configurable on the client if a runtime doesn't support the default. Similar to how we define the storage implementation in React Native / Expo projects: https://supabase.com/docs/guides/getting-started/tutorials/with-expo-react-native?queryGroups=auth-store&auth-store=secure-store#initialize-a-react-native-app.

[haeniya]

Hi @filipecabaco do you have an update on this issue? And maybe an idea how we can work around it for the moment?
Thanks.

[filipecabaco]

Now that I'm finally stabilizing things in realtime-js accessToken callback I'm thinking of:

• Selectively import ws depending on the runtime
• Selectively choose the right "Worker" depending on Runtime

I will use the same principle from https://github.com/supabase/supabase-js/blob/master/src/lib/constants.ts#L6-L16

Hopefully this will help with:

• dependencies working
• proper background heartbeat

Plus the accessToken callback I believe will also help.

Hopefully I will get this ready today so we can iterate on it on the next branch of realtime-js 👀

WDYT?

[haeniya]

Ok, great. Thanks for the update @filipecabaco. Let me know if I can support or test anything.

Regarding the different workers for the heartbeat - could it be feasible to make this configurable on the client similar to how we define the storage implementation in React Native / Expo projects: https://supabase.com/docs/guides/getting-started/tutorials/with-expo-react-native?queryGroups=auth-store&auth-store=secure-store#initialize-a-react-native-app?

Not sure if that would work but just as an idea.

[filipecabaco]

Yes that's what we already allow 👍we have a "default work" but we allow users to override them so I will follow the same idea.

I'll first focus on the WS issue as that is the biggest issue: having it working in Expo

After that is tackled we'll check the worker track potentially in a different issue

But as a FYI this will be the focus of the next changes in realtime-js

Thank you and I'll ping here looking for help for tests and implementation questions 🙏

[haeniya]

Hi @filipecabaco, any update on this? Can you give a rough estimate on when this will be fixed?
Many thanks.