BUG: Not getting latest information about participants in the room.

[vivekimsit]

Expected behavior

I should be able to get the correct participants list when I join the meeting.

Describe the bug (unexpected behavior)

I am listening for the joined-meeting event and in the event handler I am calling the callObject.participants() method to get all the participants in the meeting including the local participant but it seems to return just the local participants, on logging to the console I see that the value is updated after some time for example console.log(...) prints {local: {...}} but when I click on it then I can see other objects as well.

Steps to reproduce

NA

Screenshots

NA

System information

* Device: Macbook pro M1 * OS, version: Monterey * Browser, version: Chrome 102.0.5005.115 # Additional context

[pringshia]

I am also dealing with the same issue at the moment. Is it that the callObject state takes some time to "sync up" after the joined-meeting event?

My use case is that I'd like a user that joins a room to take on a username dependent on who else is in the room, finding that difficult to do with the current set up.

[mklepaczewski]

I have a related issue where I listen for the participant-counts-updated event, but in its handler, I still see the old participant count.

[mattieruth]

Hi! Thank you for submitting this issue. The way this process works is that joined-meeting event fires to indicate that you have successfully connected to the server and have been accepted into the room. The server then begins sending the participant data in batches of 50, so it is expected that at the moment of joining, you only know about your local user. Participants already in the room will then start appearing in the participants() list corresponding to the participant-joined event for each participant. This process of sending participants in post and in batches is required in order to ensure neither the client or server are overwhelmed.

In general, we have found that the primary need for UIs at that moment of join is to know how many participants are in the meeting. For this, @mklepaczewski is right to use participantCounts() and the participant-counts-updated event for getting real time, accurate numbers on the participants in a room. This count is available at the time of joined-meeting and is sent as part of the messaging from the server so is guaranteed to be accurate (minus network delays 🙂 ).

If the counts and using the existing participant-joined events does not resolve your issues, I'd love know more about your use cases.

[mattieruth]

Apologies, @mklepaczewski, I just realized you seem to be saying there's a bug in the participant-counts-updated event. Can you expand on that or submit a separate issue?

[pringshia]

Hi! Thank you for submitting this issue. The way this process works is that joined-meeting event fires to indicate that you have successfully connected to the server and have been accepted into the room. The server then begins sending the participant data in batches of 50, so it is expected that at the moment of joining, you only know about your local user. Participants already in the room will then start appearing in the participants() list corresponding to the participant-joined event for each participant. This process of sending participants in post and in batches is required in order to ensure neither the client or server are overwhelmed.

In general, we have found that the primary need for UIs at that moment of join is to know how many participants are in the meeting. For this, @mklepaczewski is right to use participantCounts() and the participant-counts-updated event for getting real time, accurate numbers on the participants in a room. This count is available at the time of joined-meeting and is sent as part of the messaging from the server so is guaranteed to be accurate (minus network delays 🙂 ).

This is useful info! I think the (already pretty excellent) docs may benefit from having this detail included, to avoid others from being confused.

[mattieruth]

Thanks for the suggestion @pringshia -- I have done just that here and will now close this issue.