Hey team, can someone from livekit team help us understand why were multiple agent sessions created for the same room?
The most likely explanation is that they were explicitly dispatched to the same room: Agent dispatch | LiveKit Documentation as you can specify the room_name in the API, is that possible?
I observed this for the first time this morning. The symptom was a user connected to a room but left in complete silence (app looked like it connected but spoke and heard nothing).
No Livekit Analytics were available for either “replica”. One lasted for 45 seconds with 1 participants (I’m guessing the silent room with the user). Another lasted for 6 minutes with 2 participants. I can provide details to Livekit staff for review.
We don’t have explicit dispatch enabled, so that shouldn’t be the case.
It seems strange that session RM_gSrXNWNsT6SS has no participants, but the agent joined (and the room got created). My best guess is that the user had connection issues - perhaps that same user tried multiple times which is why you see several contiguous sessions. These sessions were 10 hours ago and we haven’t had any similar reports around that time, or since. There are no smoking guns in the server logs but there are lot messages about network issues.
Got it - do you have any recommendations to handle such connection issues then? Since every time the agent will join, it will re-start the session.
I don’t think it’s restarting the session, because although it’s the same room name, different sessions (room IDs) are created. If the rooms were not closing I would suggest you look at your logic around room closing, but I think this was just the same person with connection issues trying to connect. For the room name, I guess that is generated by your token server.
Okay, we are seeing the same issue for our production agents.
So we create room using room creation api and depend on auto dispatch for agents. The behavior is similar to above mentioned and we are not able to find root cause. Same room name, different session id. Two agents came into the same room not directly but inbetween ie while an agent was speaking, another one intercepted and took over and other one left.
Few preventive measure I’m trying out is -
- Manual agent dispatch during room creation
- Adding a request_fnc in Agent worker options to check the metadata before accepting jobs. (Noticed the new agent does not have metadata we are setting so filtering requests based on that)
- We saw an instance where the room didnt close on its own, and a new session got created wo metadata (means we didnt do it explicitly) and an agent joined from there. So explicitly closing the room from our end without depending on auto closing whe participants are left.
Still monitoring and the above mentioned changes are in development so not a clear solution but defensive mechanisms