Ensuring Unique Room IDs with Dynamic Room Names

When your application creates and tears down rooms with the same name in rapid succession—common in apps where room names derive from static values like user IDs—you may encounter unexpected Room ID reuse. This guide explains why it happens and how to guarantee unique Room IDs every time.

Problem

If you delete a room and quickly create a new room with the same name, the new room may reuse the previous Room ID. This behavior is non-deterministic: sometimes you get a new Room ID, sometimes you get the old one. This can cause confusion when you need each meeting instance to be uniquely identifiable.

Why This Happens

Several factors contribute to Room ID reuse:

Race condition between delete and create

When you call DeleteRoom, the request updates the database to mark the room as ended. If you immediately issue a CreateRoom request with the same name before the database update completes, the new request may see the previous room as still open and reuse its Room ID.

Auto-termination timing

If no explicit DeleteRoom call is made, LiveKit's auto-termination logic applies. Rooms auto-close after a departure timeout (default: 20 seconds) when there are no participants. Then a sweeper process finalizes cleanup, which can take another 30–45 seconds.

Database propagation delays

Occasionally, connectivity issues between nodes and the database can delay the DeleteRoom operation, leaving stale room state briefly visible to new create requests.

Important Caveats

• If you reuse the same room name within a short window (under 30–60 seconds), there's no guarantee the system will generate a new Room ID.
• Relying on a static room name (like a user ID) without any uniqueness suffix makes this more likely to occur.
• Rapidly polling endpoints like ListParticipants will not fix this issue and may add unnecessary load.

Solution

Use a unique room name each time you create a new meeting.

You can still base it on your user ID, but add a unique suffix such as:

• A timestamp
• A random string or UUID
• An incrementing counter

Before (static room name)

room_name = "user_12345"

After (dynamic room name with timestamp)

room_name = "user_12345_20250724T081259Z"

After (dynamic room name with UUID)

room_name = "user_12345_ab12cd34"

This guarantees that each CreateRoom request will always create a new, distinct room with a unique Room ID.

Alternative: Allow Time Between Deletion and Recreation

If you must reuse the same static room name, allow at least 1–2 minutes between deletion and recreation to ensure cleanup completes. However, this approach is fragile and not recommended for production systems.

Debugging Room ID Reuse

If you see unexpected reuse of Room IDs:

1. Check your logs for the timestamps of DeleteRoom and CreateRoom calls.
2. Confirm whether the calls overlapped within the 30–60 second window.
3. Verify that your room naming strategy includes a unique element.