https://livekit.io logo
Join Slack
Powered by
Hello! We have a lot of open rooms which are not b...
# ask-ai
a
Hello! We have a lot of open rooms which are not being automatically cleaned up. It started this morning and I don't believe we have changed anything on our end. What could be the issue?
✅ 1
t
Thanks for reaching out, Madeleine. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — I’m sorry you’re seeing rooms not getting cleaned up. I’ll help troubleshoot. First, quick questions to narrow this down: • Are you using LiveKit Agents in these rooms (bot/agent participants)? • Have you recently deployed any agent changes or server updates this morning? • Do you have room IDs or an example room I can inspect (or a timestamp range when the issue started)? What likely causes and immediate checks • Agent participants staying connected will prevent auto-cleanup. If agents remain in the room after human participants leave, rooms stay open. Check agent session state and whether 
close_on_disconnect
/ 
delete_room_on_close
is set as you expect. • Departure timeout: rooms close only after the departure timeout (default ~20s) plus the sweeper delay (~30–45s). If your load is high, cleanup can appear delayed. • Room ID reuse / race conditions: rapidly re-creating rooms with the same name can cause cleanup delays. Using unique room names (UUIDs or timestamps) avoids this. Immediate actions you can take • Verify agent sessions: confirm agent participants are actually disconnected when users leave and that 
delete_room_on_close
(or equivalent) is enabled for agent sessions. • Manually delete stuck rooms via the server API (
deleteRoom
) for any urgent cleanup. • Check recent deploys or config changes that might affect session close behavior. If you share whether you’re using agents and one example room ID or timestamps, I’ll check the most likely causes and suggest the exact setting change or the API call you should run. Sources: Agent session | LiveKit Documentation | Avoiding Room ID Reuse When Re-Creating Rooms With the Same Name | Job lifecycle | LiveKit Documentation, with interactive elements
a
tell me more about 
delete_room_on_close
t
Thanks — I’ll explain 
delete_room_on_close
and how to use it. What it does • 
delete_room_on_close
makes the room be deleted immediately when an agent session ends, disconnecting any remaining participants. It prevents leftover rooms after the session shuts down. Defaults & availability • Default: 
False
. • Available in the Python SDK. Node.js does not expose this flag; you must delete the room via the server API instead. How to use (Python) 1. Set it in 
RoomOptions
when starting an `AgentSession`:
Copy code
await session.start(
    agent=boss_agent,
    room=ctx.room,
    room_options=room_io.RoomOptions(delete_room_on_close=True),
)
1. When the session ends (e.g., 
session.shutdown()
), the room will be deleted automatically. If you’re not using Python • Call the server API 
deleteRoom
after the agent session ends to remove the room immediately. If you want, tell me which SDK you’re using (Python or Node.js) and an example room ID — I can give the exact API call or a code snippet to delete stuck rooms. Sources: Agent session | LiveKit Documentation | Job lifecycle | LiveKit Documentation | Build a salary negotiation coach with a LemonSlice avatar | LiveKit, with interactive elements
a
can I add a delay?
t
Thanks — regarding your question about adding a delay to `delete_room_on_close`: • 
delete_room_on_close
deletes the room immediately when the agent session ends. There is no built‑in option to add a delay to that behavior. • If you need a delay, implement manual deletion in your agent logic instead of using `delete_room_on_close`: a. End the session without 
delete_room_on_close
. b. Wait the desired amount of time (e.g., 
await asyncio.sleep(seconds)
in Python). c. Call the server API 
deleteRoom
(or 
api_client.room.delete_room(...)
) to remove the room. Tell me which SDK you’re using (Python or Node.js) and how long a delay you want, and I’ll provide a short code snippet for that flow. Sources: Agent session | LiveKit Documentation | Avoiding Room ID Reuse When Re-Creating Rooms With the Same Name | Job lifecycle | LiveKit Documentation, with interactive elements
a
what is the import for room_io
t
You can import 
room_io
from `livekit.agents`:
Copy code
from livekit.agents import room_io
Sources: Agent session | LiveKit Documentation, with interactive elements
a
we are now getting a delete room error in our application that we were not seeing previously
Copy code
in delete_room\n return await self._client.request(\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"/bundle/lib/python3.12/site-packages/livekit/api/twirp_client.py\", line 129, in request\n raise TwirpError(\nlivekit.api.twirp_client.TwirpError: TwirpError(code=not_found, message=requested room does not exist, status=404
t
Thanks — I can help troubleshoot the 404 
requested room does not exist
error when calling 
delete_room
. What this error means • The server cannot find a room with the name you passed to 
delete_room
. Common causes: ◦ The room was already deleted (double-delete). ◦ A race condition: you called delete before the room was fully created or after auto-cleanup finalized. ◦ The room name/ID passed is incorrect or malformed. ◦ Temporary DB/state lag or connectivity issues causing the room to be unavailable. Quick checks to run • Confirm the exact room name you pass to 
delete_room
(the API identifies rooms by name). • Check logs/timestamps: does a prior delete or auto-close happen before this call? Look for earlier delete calls, agent shutdowns, or auto-cleanup events. • If you recreate rooms with the same name, add a short delay (1–2 minutes) or better, use unique names (UUID/timestamp) to avoid reuse/race issues. • If you suspect transient state lag, retry the delete once after a short backoff and log the room existence before attempting deletion. If you want, share: • The SDK and code snippet you use to call 
delete_room
(Python or Node). • An example room name/ID and the timestamps around create/delete attempts. I can then suggest a short code change (existence check + safe retry or unique naming) or a specific retry/backoff snippet for your SDK. Sources: Avoiding Room ID Reuse When Re-Creating Rooms With the Same Name, with interactive elements
a
this worked until an hour ago
t
Sorry — I know this started suddenly and is disruptive. Since delete worked until an hour ago, let’s narrow the likely causes quickly: 1) Quick checks (please confirm) • Any deployments, config changes, or agent updates in the last hour? • Are you reusing the same room names (vs. UUID/timestamp)? • Which SDK/version are you calling deleteRoom from (Python or Node)? • Can you share one example room name and the create/delete timestamps? 2) Most likely causes given it just started • A race condition or double-delete: the room was already deleted by auto-cleanup or another process before your delete call. • Transient state/DB lag causing the room to be briefly unqueryable. • A recent deploy changed how/when rooms are deleted (agent behavior or API calls). 3) Immediate mitigations you can apply now • Add an existence check + safe retry with short backoff before calling delete: ◦ Check room exists, then call delete; if 404, treat as success. • If you reuse names, switch to unique names or add a 1–2 minute delay between delete and recreate. • Log full request payload and timestamps for create/delete calls to spot ordering issues. If you share SDK and a sample room name + timestamps, I’ll give an exact retry/try-except code snippet you can drop into your app. , with interactive elements
2 Views
Open in Slack
PreviousNext
Powered by