livekit / client-sdk-js

LiveKit browser client SDK (javascript)
https://livekit.io
Apache License 2.0
368 stars 149 forks source link

ConnectionStateChanged event not triggering upon mobile participant disconnection #1120

Closed symo4b closed 6 months ago

symo4b commented 6 months ago

I believe we've encountered a bug related to the ConnectionStateChanged event within our system. In a scenario where there are two participants in a room, the second participant joined from a mobile device. Even after closing the connection on the mobile device, the system continues to display two participants on the other end.

Upon investigation, it appears that the ConnectionStateChanged event, which should be triggered upon changes in connection status, is not being called at all in this situation. As a result, the system fails to update the participant count accurately, leading to incorrect information being displayed.

Expected Behavior: The ConnectionStateChanged event should be triggered when a participant's connection status changes, such as when they disconnect from the room. This event should update the participant count accordingly, ensuring that the correct number of participants is displayed.

Impact: This issue affects the accuracy of participant count display within the system. It may lead to confusion for users who rely on this information to gauge the status of their sessions.

Reproduction

  1. Have a room set up with two participants.
  2. Have the second participant join from a mobile device.
  3. Close the connection on the mobile device.
  4. Observe that the ConnectionStateChanged event is not triggered, and the participant count remains unchanged.

Logs

No response

System Info

Browser: latest chrome browser

Severity

blocking all usage of LiveKit

Additional Information

No response

lukasIO commented 6 months ago

RoomEvent.ConnectionStateChanged is for local participants. What you’re looking for is RoomEvent.ConnectionQualityChanged transitioning to ConnectionQuality.LOST and, eventually, RoomEvent.ParticipantDisconnected. Both events aren’t perfect and also will, by design, always have a bit of a delay until they are reported. You can always try to hook into DOM events and perform a manual disconnect. E.g. when you know for a fact that a user is about to close your app/the browser tab, then you can try to call room.disconnect() . In most cases this should still make it through to the server, resulting in a faster feedback for other users that the participant disconnected. The JS SDK already tries to be smart about that by hooking into some of these events and calling disconnect as a result here. But from your app you might have more options to deal with this than we have from a SDK perspective. E.g. you could prompt your users with a are you sure you want to leave type of message. Support for that and how well that works ultimately comes down to browser support though. Support for hooking into page closes is very spotty and differs between different browser engine implementations.