realtime subscription reliability
I've noticed in real-world testing of my realtime multiplayer application that in the odd case, users may miss updates. I assume this happens because the connection stops working momentarily, leaving a small gap between the connection not working and someone sending an update. I am building a react native application and subscribing to database changes via broadcast. How can I stabilize the connection better to not miss out on these rare/random events? Anyone else facing a similar problem?
11 Replies
You have to basically deal with any connection error and restart the subscription AND check for any missed messages. You would need to keep track of last successful update by incrementing id or time. Then reconnect and fetch all missed messages. It is possible to use the realtime.messages table as it keeps a history for a some short period of time. Or you have to have your own table have dates. If you do deletes then things are more complicated and using a messages for the operations is needed.
If the connection ever drops for background tabs, low power mode of mobile devices, internet connection, etc then you lose any messages during that period. This is true even if you let realtime reconnect automatically as there is no built in queue. I stop the connection and restart a new everytime the connection drops. I actually check if the tab is visible with the visibility handler and don't connect again until it is visible. Then after connecting would reload anything missed.
This is old and links an even older github discussion on the issue and dealing with it. This was postgres_changes, but same applies for broadcast. https://github.com/GaryAustin1/Realtime2 A study and not a final solution.
Ok from what I understand there are 2 places that cause issues 1. initially setting up the connection (there could be data loss here as there could be changes while this is happening) 2. handling when the connection disconnects - add retry logic. I saw this reddit post that handles the retries, is this something that should work? And then adding to this, any time the channel is SUBSCRIBED again (or for the first time), it will load the necessary state for that user. Does that make sense?
Reddit
the_brawler1's comment on "Subscription sometimes doesn't get real-...
Explore this conversation and more from the Supabase community
You do need to get any existing data since last successful update to the client AFTER the connection is established or you could miss data in that small window.
I'll try and look at that post, but it won't be this weekend.
Not sure on your last comment if you mean Supabase will reload the state or that link shows reloading the state. Supabase will NOT reload any events that have happened in the past.
Remember that the client will try and reconnect if the connection drops. That is not good if you don't want to miss data. You need to know there was an error/drop and handle the reconnect on your own.
the reddit post: 1.watches for CHANNEL_ERROR 2. unsuscribes 3. subscribes again
Yes that is what I do.
so thinking in (3), i would load data
But I don't subscribe again if the tab is not visible as it will just error again shortly.
im working on mobile, so the app would go into the background. When that happens, do the subscriptions disconnect? When returning back (foreground), do they automatically reconnect again?
If the device goes into low power mode they will likely disconnect. I only do browser stuff and on mobile it would disconnect when the tab is not visible which includes background. Even browsers on desktop assume they should go into low power mode and slow down their timers.
But you should log your .subscribe status out and see what happens. If you get any error or close then you will miss data if there is a change before realtime reconnects again which it seems to do for awhile and then gives up.
There is a webworker option now in realtime-js that helps prevent this slow timer case... but to me it still does not matter because you could disconnect for internet or changing connections moving around, etc. So handling any drop is needed if you want 100% changes to a table.
Ok, I will mess around with this, I will reach out again if i have more questions. Thank you