Hello!
My team and I are trying to debug a specific session case with 3 participants in the room. Two of the participants had a stable connection and could have a normal conversation. However, the third one seemed to be "lagging” when we looked at the session recording in the 3rd party tool.
Although the participant was lagging, she had never left the call. At least according to the Livekit logs. Throughout the session, she received the “participant_joined” event multiple times, but she never received the “participant_left” event. You can see it at the Dashboard screenshot (User ID: bb583388-0f3e-4198-a461-4f4deb94ce77)
I’d like to ask you what the specific trigger is to receive the “participant_joined” event, even if a user hasn’t left, and why there are so many instances of it? Any help would be very welcome.
Here’s the room ID to facilitate looking at your internal logs: RM_NhSzG9cy69pe
Maciej
I see the logs. Checking our server logs for this room, it looks like the session was migrated to a different node for load balancing purposes and for some reason (probably related to the “lagging” you mentioned) this participant had difficulty joining the migrated session.
This shouldn’t happen. Can you check you are on the latest version of our client SDK. Also, it might be worth looking at your client logs around this time to see if there are any clues.
I don’t see any other similar issues for other customers around this time, so this might be an isolated incident.
@darryncampbell Thank you for your prompt reply. Here are the characteristics of our livekit integration. A group of users is attending a so-called “event” in which they collaboratively learn English in a video call. We rely on LiveKit webhooks to intercept events of users leaving and joining, so we can accurately process the formation of the group in the back-end.
Users remain in the same “event” at all times, and whatever happens on the Livekit side, in theory, shouldn’t be reflected in our video call. However, we see that one participant remained in the same “event” but she couldn’t see or hear other participants as if she was in the other room. She was active at all times, though, and didn’t leave the call until 30-40 minutes in the session.
Do you think migrating to a different LiveKit node can affect how users interact with the room? Perhaps you’re right, and while migrating to the different node, the user couldn’t connect to it, resulting in an “isolated” room.
If this were the case, how could we prevent it from happening again in the future?
We’re running on the following packages, which are quite outdated as far as I can see:
- “livekit-client”: “^2.7.0”
- “@livekit/components-react”: “^2.6.11”,
- “@livekit/components-styles”: “^1.2.0”,
- “@livekit/krisp-noise-filter”: “0.2.13”,
- “@livekit/track-processors”: “^0.7.0”,
It shouldn’t do, the transition should be seamless and not noticed by the user, but in this case something seems to have gone awry
We’re running on the following packages, which are quite outdated as far as I can see:
Before replying to this original thread i searched for similar reports internally, I saw one (at a different time to your report) and the solution there was to upgrade to the latest version of the client SDK, after which the issue went away
Alright. Thanks for looking into the internal logs for me. I really appreciate it.
In our case, this was the first incident and so far the only one. I’ll let my team know about our conversation and we’ll do our best to keep SDK up to date.
Thanks!
