@Daniel_Alvarado, the terminology gap is doing most of the work here. The Cloud “Sessions” dashboard is an observability/historical view, not the live room state. If listRooms returns nothing and deleteRoom says the room doesn’t exist, the actual SFU room is already gone. What’s “stuck active” is the dashboard’s view of the session record.
Most likely cause: an egress (or ingress) job still attached to that session hasn’t finalized, so the dashboard keeps it marked active until that job completes. Run lk egress list and check for anything still in EGRESS_ACTIVE or EGRESS_ENDING referencing that room. Stop it with lk egress stop <egress_id> if so.
If no egress is hung and the display stays active past 10-15 minutes, it’s likely a dashboard rendering issue on Cloud’s side. Ping @CWilson or @darryncampbell at that point.
Hey guys, not sure if you did anything last time, but right after you responded, shortly after the two sessions that were hung ended. However, it is happening to us again. Not sure if we’re doing anything wrong when it comes to closing or ending meetnigs. But this will eat up our egress and participantt minutes.
Here are two examples where on code I try calling room close, but I get that the room does not exist. And those are the two room names that have been live for 1,200+ minutes.
@Daniel_Alvarado, Glad to hear the original diagnosis cleared the first sessions. The new instance (1,200+ min in the dashboard, deleteRoom returning “room does not exist”) confirms the same shape: the SFU rooms are already gone (the 404 from deleteRoom is the authoritative signal), and what’s stuck is the dashboard’s session record.
Your code path is correct. The deleteRoom 404 just means there’s nothing left to delete on the SFU side, which is also why listRooms shows nothing.