```await lkapi.room.delete_room(api.DeleteRoomRequ...
# ask-ai
b
Copy code
await lkapi.room.delete_room(api.DeleteRoomRequest(room=room_name))
What role does this play? I understand that it deletes the room with the name room_name, but if there are multiple rooms with the same name, does it delete all of them, or only one?
t
Thanks for reaching out, 최윤지. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — great question about
delete_room
. • The
delete_room
call deletes a single room identified by the exact
room_name
you pass. • LiveKit does not allow multiple active rooms with the same name, so there won’t be multiple simultaneous rooms to delete. When you delete a room, participants are disconnected and that single room is removed. • Note: if you quickly recreate a room with the same name, Room ID reuse can happen due to cleanup timing, but
delete_room
still targets the one existing room with that name. If you’d like, tell me the language or SDK you’re using and I can show a short example or confirm the API response you’ll receive. Sources: Connecting to LiveKit | LiveKit docs | Avoiding Room ID Reuse When Re-Creating Rooms With the Same Name | Managing rooms | LiveKit docs
b
There is a room currently in progress like this: • Room name: b6587fc8-e9a1-4583-8c0d-4a422e861f23 • Status: In progress • Duration: 1,325 minutes • Participants: 0 • State: Active However, when I send a delete request for this room, it fails with the following error:
Copy code
TwirpError(code=not_found, message=requested room does not exist, status=404)
Is it possible for this situation to occur?
t
Thanks — I’m responding to your question about why deleting that active, empty room returns
TwirpError(code=not_found, message=requested room does not exist, status=404)
. This situation can happen. Possible causes: • The room was already logically closed or is in the middle of cleanup, so the DeleteRoom API cannot find it even though the UI/monitoring still shows it as active. • An automatic cleanup (e.g., after
empty_timeout
) started and removed the room from the API’s view while residual processes (egress/agents/recordings) still appear running. • A race or replication/caching lag in a distributed deployment caused inconsistent state between the UI and the API. • A typo or wrong room identifier in the delete request. Next steps to help diagnose and resolve: 1. Confirm the exact room name you’re sending in the delete request (copy/paste to avoid typos). 2. Call the
ListRooms
API right before delete and share whether the room is returned. 3. Check server logs around the delete attempt for messages about cleanup, egress, or errors. 4. Verify any egress/agent/recording jobs for that room are stopped — those can keep tasks running after participants leave. 5. Share the timing: when the room became empty vs when you attempted delete, and whether you recently recreated a room with the same name. If you share the
ListRooms
result and the exact request payload (room name) or relevant log snippets, I’ll help pinpoint which of the above is occurring and recommend the next action. Sources: Avoiding Room ID Reuse When Re-Creating Rooms With the Same Name | Managing rooms | LiveKit docs