Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

calls to supabaseListener.subscribe() very slow to reconnect #593

Closed
paul-brenner opened this issue Nov 6, 2024 · 3 comments
Closed

calls to supabaseListener.subscribe() very slow to reconnect #593

paul-brenner opened this issue Nov 6, 2024 · 3 comments
Labels
bug Something isn't working

Comments

@paul-brenner
Copy link

Recently I'm seeing that it can take up to 60 seconds for supabaseListener.subscribe() to complete. I just confirmed this is still true on v2.21.0.

This didn't happen previously so I'm trying to chase down whether it is a change in supabase or if I'm doing something wrong in my implementation. The part on my side I'm suspicious of is that I don't know what the best practice is for actively disconnecting/reconnecting.
Should I:

  1. Call .unsubscribe() when my app goes into the background and then calling .subscribe() when it becomes active again
  2. Do nothing when the app goes into the background, when it becomes active check if .status != .subscribed and only call .subscribe if that is the case
  3. It doesn't matter

I opened a ticket with support because I was also seeing this in the realtime logs, so sorry if this is creating a dupe. The log messages look like:
"UnknownError: RPC call error" and "ErrorOnRpcCall: %{\n error: {:error, {:erpc, :timeout}},\n mod: Realtime.Tenants.Connect,\n func: :connect,\n target: :"realtime@2600:1f10:4c1b:cc02:d97a:cd4d:6bf:bc61"\n}"

@paul-brenner paul-brenner added the bug Something isn't working label Nov 6, 2024
@grdsdev
Copy link
Collaborator

grdsdev commented Nov 6, 2024

Hi @paul-brenner

Regarding reconnecting taking too long to complete, I need to check with the backend team. Can you share the ticket ID so I can follow up internally with them?

About best practice for reconnecting, I'd recommend you do option 2, check if status != subscribed and call subscribe.

I plan to implement in the library the logic for automatically handling reconnection logic in case of background/foreground and also loss of internet connection, to have a robust socket connection.

Issues for tracking such changes:

@paul-brenner
Copy link
Author

Thanks!
The ticket id is: 15893104508

I'll try what you recommended and see if it helps.

@paul-brenner
Copy link
Author

This issue seems to be resolved for me now though I can't say if it was the recommended changes or improvements on the supabase server side

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants