what happens if i set room departure timeout to a ...
# ask-ai
a
what happens if i set room departure timeout to a really low value? (like 1 to 5 secs)?
✅ 1
t
Thanks for reaching out, Sebastián. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — regarding setting the room
departure_timeout
to 1–5 seconds: • The room will be automatically closed almost immediately after the last participant leaves. • Any background work or delayed actions that expect the room to remain open briefly may be interrupted or fail. • If you recreate a room with the same name quickly, you may run into race conditions or Room ID reuse issues. • If you use
delete_room_on_close=True
for sessions, that forces deletion immediately and bypasses the timeout behavior. If you tell me what you’re trying to achieve (e.g., save resources, prevent reuse, support short reconnects), I can recommend an optimal timeout value or alternative approach. Sources: Agent session | LiveKit Documentation | Job lifecycle | LiveKit Documentation | Avoiding Room ID Reuse When Re-Creating Rooms With the Same Name, with interactive elements
a
we use an approach of always on rooms, we create a room with participant and an agent, after a timeout we disconnect and reconnect to a new room dispatching a new agent, letting the old one drain in that case, what should be a correct room? because i see left over rooms with 0 participants yet active
t
Thanks — I’m responding to your “always on rooms” flow and why you see leftover rooms with 0 participants. A few quick points you can act on now: • If your
departure_timeout
is short, rooms will remain open only for that grace period after the last participant leaves. Short timeouts can still leave rooms "active" briefly; set it longer if you need the room to stay available after disconnects. • Use
delete_room_on_close=True
to force immediate deletion when the AgentSession ends if you want no leftover rooms. • Ensure the session is actually closing: AgentSessions normally close when the linked participant leaves unless
close_on_disconnect
is configured to keep it open. Verify your
RoomOptions.close_on_disconnect
setting. • Avoid reusing static room names. Use unique names (timestamps/UUIDs) to prevent Room ID reuse and confusion when creating new rooms quickly. • Add cleanup/monitoring via webhooks (
participant_left
,
room_finished
) or a periodic sweep to detect and remove rooms with 0 participants that remain active unexpectedly. A couple quick clarifying questions so I can recommend exact settings: 1. Do you currently set
delete_room_on_close
or
close_on_disconnect
in your RoomOptions? 2. Are you using unique room names per session or reusing a fixed name? Tell me those and I’ll suggest concrete timeout values and a cleanup pattern that fits your rolling-agent drain flow. Sources: Agent session | LiveKit Documentation | Avoiding Room ID Reuse When Re-Creating Rooms With the Same Name | Deployment reliability on LiveKit Cloud | LiveKit | Job lifecycle | LiveKit Documentation, with interactive elements