I want to ask if what I did makes sense. So I have a Phoenix LiveView app I built that has users join and leave a lobby and I track this separately using Phoenix Presence. But it had this issue where it would open multiple websockets (presumably it opens one then closes one, then opens another) when a user joined (to my knowledge this is normal) and when it opened multiple websockets, it would track the presence of the same user multiple times because using the Presence.track() is asynchronously called and would be called each time the user opened a websocket. When the user left, it would remove the tracking in presence for only one of the duplicated users. What I think was happening was the multiple websockets and tracking the presence had a race condition and it didn’t know the first user even left. I think the first user left before the Presence.track() was done, so the Presence tracking never knew that user left. So what I did to combat this is I set up an actor that can be called and this calls Presence.track() synchronously and also has an internal list that it checks to make sure it doesn’t duplicate the user. I tested it and it works as intended even though the user still opens multiple websockets when they join. Also works fine if the user refreshes the page. Again, my question is whether or not this makes sense. In my eyes its sort of a band-aid.
1 Like
I think it’s a band-aid, but I could be missing something.
A pattern for pubsub subscriptions with liveview apps is to only subscribe if the socket is connected. So, you’ll see people using connected?/1 and doing the subscription inside an if-block. Are you already doing that? If not, this looks to be an example with Presence: Phoenix Presence with Phoenix LiveView · FullstackPhoenix.
1 Like
Yes, I’m doing the same thing in the example you tagged.
Not sure then. Do you have a link to the repo?
