Switching to and from breakout rooms may not work as expected due to message/request order

[danxuliu]

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

---

When breakout rooms are started first the lobby is disabled in the child rooms and then the status is changed. This causes a roomlist->update signaling message to be sent with the new lobby status, and then a switchto signaling message to be sent with the room to change to.

Similarly, when breakout rooms are stopped first the status is changed and then the lobby is enabled in the child rooms. This causes the signaling messages to be sent too, although in reverse order.

When the WebUI receives the roomlist->update message it updates the room properties, and when it receives the switchto message it switches to the specified room. Therefore, when breakout rooms are started the WebUI changes to the child room without showing its lobby, and when breakout rooms are stopped it changes to the parent room before the lobby is shown in the child room. All working as expected.

However... the WebUI could be fetching the room data independently of the signaling messages. Thus the following scenario could happen (although it should not happen often):

• The WebUI sends a request to get the room data. At this point the lobby is enabled.
• Breakout rooms are started
• Signaling messages are sent and processed by the WebUI
• The participant is moved to the child room
• The response to the request to get the room data is received. The lobby is enabled again in the WebUI once the participant switched already to the child room.
• In any case, the lobby would be visible only for a brief time, as even if the properties in the signaling message are updated the full room data is fetched again when roomlist->update is received

More problematic is the opposite scenario (but, again, it should not happen very often, and even less than the other):

• Breakout rooms are stopped
• The WebUI sends a request to get the room data. At this point the lobby is enabled.
• The response to the request to get the room data is received. The lobby is enabled again in the WebUI, which kicks the participant out of the call.
• Signaling messages are sent and processed by the WebUI
• The participant is moved back to the parent room, but the participant is no longer in the call when moved, so the call is not joined again after the room change

The problem should be also minimized by the optimization to fetch only the modified rooms, but it can potentially happen due to still fetching the full room list in some cases.

Probably the solution would involve keeping track of the room data updates and ignoring stale data if a signaling message was received after the fetching was requested but before a response was received, or something similar to that.