Tracker: join/leave within broadcast_period unclear in handle_diff/2 about phoenix_pubsub HOT 5 CLOSED

Can you give more information? What exact diff are receiving in such cases?

Because of the above issue, when we had a hotspot restart its software, we would get a leave, followed immediately by a join all within the default 1500ms

This makes sense as the key did leave then rejoin. Your logic needs to consult the metadatas for the key to know if they have left from all devices, joined for the first time, etc. It's not clear from your description that something is wrong and sounds like it is working as expected.

For example here is the snippet from our js presence client with logic:

let presence = new Presence(channel)

// detect if user has joined for the 1st time or from another tab/device
presence.onJoin((id, current, newPres) => {
  if(!current){
    console.log("user has entered for the first time", newPres)
  } else {
    console.log("user additional presence", newPres)
  }
})

// detect if user has left from all tabs/devices, or is still present
presence.onLeave((id, current, leftPres) => {
  if(current.metas.length === 0){
    console.log("user has left from all devices", leftPres)
  } else {
    console.log("user left from a device", leftPres)
  }
})

from phoenix_pubsub.

Hey @chrismccord thanks for the speedy reply.

In my system the hotspots are devices running on OpenWRT so no browsers and no multiple connections for the same key.
The issue is that in the handle_diff/2 you get essentially 2 lists, one with the joins and one with those who have left.
But in our case when the software reconnects we have a leave, followed by a new join, but it could as well be a join with an immediate disconnect, we cannot see this. There is nothing to indicate in which order these have happened.
I don't know if this makes it more clear.
I had a conversation about it today on Slack (https://elixir-lang.slack.com/archives/C03QQCV4H/p1711540815449919).

from phoenix_pubsub.

BTW, I am not using Phoenix.Presence, but Phoenix.Tracker directly.

from phoenix_pubsub.

But in our case when the software reconnects we have a leave, followed by a new join, but it could as well be a join with an immediate disconnect, we cannot see this.

You can see this :)

The phx_ref's in the diff uniquely identifies the items. A matching phx_ref in the joins and leaves for a given key necessarily means they joined and then left (your immediate disconnect scenario above). Likewise mismatched keys means one of the entries left, but a new one joined. Thanks!

from phoenix_pubsub.

Ah!

from phoenix_pubsub.