Realtime websocket loses connection regularly when browser tab goes to background

[GaryAustin1]

Bug report

Describe the bug

With a simple subscription to a table (RLS or Not) the websocket drops and reconnects every 3 minutes after 5 minutes of tab in background. Verifying on Windows 10 with Chrome and Edge. Note going to different tab on browser puts other tabs in background mode.

To Reproduce

var supabase = supabase.createClient("https://url.supabase.co", "auth code")
let mySubscription = supabase
.from('status')
.on('*', payload => {
console.log('Change received!', payload)
})
.subscribe((status,e)=>{
console.log('subscribe status,error',status,e);
})

Start up subscription to a table. Start Dev Console turn on networking and timestamps. Shrink browser or hide tab under others. Wait >10 minutes.
Websocket will have disconnected and connected several times.

This is a pretty bad condition for real-time if it is to be relied on at all for more than the current active window time. During each disconnect changes to the table would be missed.

It is also compounded that Supabase does not really document error and close handlers for realtime subscription at supabase.js or higher. Only here in the realtime.js description do you see error handlers. It took looking at the supabase.js code to see that one could do .subscribe((status,error)=>{console.log(status,error)} to see connection failures. OTHERWISE THIS IS A SILENT FAILURE AS THE SUBSCRIPTION KEEPS RUNNING EVEN THOUGH DROPPING POTENTIAL UPDATES. Anytime realtime drops the socket, if you want reliable data you have to reload from your tables to get all recent changes.

Expected behavior

The websocket should remain alive even when tab/window is hidden and in background mode. Realtime.js must understand different timings done by background throttle of browsers and keep connection alive.

Screenshots

Below is about 15 minutes after leaving browser in background...

System information

Windows 10
supabase.js 1.28.5
Chrome or Edge

Additional context

Out of time for a few days but I'll try and get more info on these additional issues.
EDIT: I no longer believe there is an error with multiple connections for a single user.
Further investigation posted in my next issue points to a more general realtime.js bug on losing the refreshed token on a disconnect/reconnect of the websocket for any reason (the above being one).

[GaryAustin1]

Just want to add it is understood by me, and should be understood or made clear to users of real-time, the need to monitor the subscribe and take appropriate action if the subscription fails. The reason I dug into how to watch the subscribe status is I use it as part of my online/offline logic and reload message counts when coming back online. But my overhead is such that doing this with a background tab every 3 minutes is very costly. I’ve already started down the path to use the visibility hook to not reload if hidden but it will still be painful if the user is just moving thru tabs on his screen and goes away fo 10 minutes.

[GaryAustin1]

Looking into this more I see realtime uses websocket-node. I'm hopeful there are some settings that can deal with the background tab throttle giving client more time to ping. I've found no discussions on that particular package but here are others that have had to deal with this:
https://socket.io/blog/engine-io-4-release/#heartbeat-mechanism-reversal
https://stackoverflow.com/questions/66496547/signalr-and-or-timer-issues-since-chrome-88
SignalR/SignalR#4536

[fschoenfeldt]

I see that you're using Phoenix. We're having similar issues with the websocket disconnecting after a while – mostly in an inactive browser tab.

[GaryAustin1]

Adding this comment here also on Chrome and going to 1 minute timeouts (which would break the 60 sec heartbeat).

OK, here's the new bit in Chrome 88. Intensive throttling happens to timers that are scheduled when none of the minimal throttling or throttling conditions apply, and all of the following conditions are true:
The page has been hidden for more than 5 minutes.
The chain count is 5 or greater.
The page has been silent for at least 30 seconds.
WebRTC is not in use.
In this case, the browser will check timers in this group once per minute. Similar to before, this means timers will batch together in these minute-by-minute checks.

https://developer.chrome.com/blog/timer-throttling-in-chrome-88/

[GaryAustin1]

Not directly related to the above issue (which is still there).

@w3b6x9 I'm not sure who at Supabase is the knowledge keeper of the phoenix realtime socket level stuff...

But I think it is important to understand what level of interruption a websocket can have and still have the server maintain an output queue of realtime changes to that socket.
For instance if the socket drops one heartbeat and then the reconnect process starts is the "channel" queue on the server still there and taking in realtime changes that can then be fed back down to the client on reconnect?
If so how long can the websocket not have connection before the server drops the channel?

This is important in determining when to reload a dataset because changes could have been missed.
Thanks

[w3b6x9]

@GaryAustin1 if the server doesn't receive a heartbeat for 60 seconds (this is the default for all Supabase projects running Realtime RLS but can be customized) then it will sever the socket connection. When the socket connection is severed, all of the channel processes (every topic that a client was listening to via the socket conn) dies. On reconnect, all of the topics that the client is listening to will join as new channel processes on the server.

[GaryAustin1]

I've been looking into this a bit. Unfortunately without any sort of short term queue I believe Supabase needs to make clear that when a tab is not in focus, you need to stop realtime, and plan on restarting completely on focus using the visibility event. A tab not in focus can mean just a simple go check stocks on another tab and come back. Based on further research a queue would probably only benefit desktop browsers chrome/edge. Firefox is the only browser that has no issues on desktop. I've not tested on mobile yet.

Firebase does not have these issues with their realtime as they maintain a constant copy of your query and restore behind the scenes when your tab comes back. I believe they might also use webworkers to do this, but not sure.

I was hoping for some way to at least use the 5 minutes Chrome/Edge have before they throttle timers (which kills heartbeat) to keep from reloading if someone just leaves your realtime app/tab for a minute to look at something else, but it appears that only works on desktop. On mobile devices both android with chrome and iPad with safari the results range from lost connection within a minute to 5 minutes depending on powered or battery and only tab or background tab. There appears to be no way to get consistent time before loss of connection across multiple devices and browsers.

Here are some sample traces. Note anytime there is a connect error you could lose data and in some cases the device just stops running the tab and a few old realtime events get logged and then loss of data until device/tab comes back into focus. All of these have a program running generating a constant incrementing update count, so should always be +1 if no data loss.

Edge(Chrome is similar) on windows desktop showing pretty constant visibility event + 5 minutes to failure

Edge (Chrome is similar) on windows desktop showing data loss

Android/Chrome powered (chrome has a freeze event in addition to visibility but does not seem reliable)
Loss of data from freeze to visible

iPad battery front tab going to sleep

Then I have traces where "strange" things happen like this android/chrome one... no idea why there are no retries here and code gets to keep running.

[GaryAustin1]

@w3b6x9
Can you take a look at this discussion (in particular the flowchart and then the code in the bottom reply) when you get a chance (no hurry) and comment.
supabase/supabase#5641
I've been trying to come up with a straight forward way to handle realtime across all connection failures in a reasonably performant manner. So far limited testing is good on desktop, starting on mobile devices soon.

Unfortunately the code is somewhat custom for each case of a subscription depending on table size (do you want just last x entries or whole table), the id column for keeping the "table" array updated, inserts at beginning or end and filter. I tried to push that code into an update handler.

[GaryAustin1]

EDIT: Add link
supabase/supabase#5641

[xxholyChalicexx]

This hasn't been solved yet ?

[w3b6x9]

@xxholyChalicexx we have not visited this issue yet but will investigate in the near future. Is this currently blocking you? Have you come up with alternatives?

[xxholyChalicexx]

well its not blocking but it gets annoying at times. As of now i try to catch and reconnect, i do that so that too is hit and a miss. Thankfully it doesnt have any adverse effect so for now just making it work.

[zbennett]

I just wanted to check in and see if there was any movement here?!