how do I remove stale rooms form my self hosted livekit server? I see there are many stale rooms with num of participants in it.. and some of them are 0 participants. Unable to delete them as well

Thanks for reaching out, Hiren. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

Tried deleting Room the way you've provided then it says it does not exist.. giving this error "twirp error unknown: requested room does not exist"

Thanks — I hear you: you tried deleting a room and got "twirp error unknown: requested room does not exist" even though you see stale rooms in your server UI. I’ll help troubleshoot that and get you unstuck. Quick summary of likely causes • The room you’re passing to

DeleteRoom

may not actually exist in the server’s active room store. • Room names are case-sensitive or slightly different than you expect. • There may be timing/race conditions (room is already being cleaned up by the server). • If you’re reacting to a webhook like

room_finished

, that webhook fires after the room is already removed. • Self-hosting specifics (DB/Redis propagation or version mismatches) can lead to inconsistent visibility. Please share these 5 items so I can pinpoint the problem 1. The exact room name you attempted to delete (copy/paste). 2. The output of your

list_rooms()

call (or a screenshot/text of the active room list). 3. The exact error text and stack trace (you already shared the Twirp error — any surrounding logs help). 4. Which SDK/language and the delete call you used (paste the code snippet). 5. How you deployed LiveKit (self-hosted via Docker, Helm, binary) and the LiveKit server version. Immediate checks you can run now 1. Confirm the room appears in the server’s active list: ◦ Call

list_rooms()

and check for the exact name you plan to delete. 1. Use the exact name returned by

list_rooms()

when calling

delete_room()

(room names are case-sensitive). 2. If

list_rooms()

does not show the room but the UI does, check server logs for messages like

Room finished

or

Room removed from room store

to confirm it was already cleaned up. 3. If you’re triggering delete from a webhook (e.g.,

room_finished

), don’t call

delete_room()

there — the room is already gone. 4. Verify your API credentials and endpoint are pointing at the same server instance you’re inspecting (a common cause of “it exists in UI but not via API”). If delete returns “does not exist” but the room is visible in your UI • Confirm the UI and the API are hitting the same LiveKit instance/cluster and same database/Redis. Different replicas or stale caches can show different states. • Check for a race where the room is being auto-removed (empty timeout, sweeper) at the same time you try to delete. If you prefer, paste the outputs/code here (list_rooms result and the delete call you are running). With those I’ll: • Verify the exact name/ID you should pass to delete_room() • Suggest a precise delete command/snippet • Point out any server log lines to look for if deletion still fails. Sources: Ensuring Unique Room IDs with Dynamic Room Names | LiveKit

I'm trying to delete the room by its SID as well as room's exact name that was returned with list_rooms like you said. Restarting livekit service would solve this issue??

Thanks — I understand you’ve tried deleting by both SID and the exact name from

list_rooms

, and you’re wondering if restarting the LiveKit service will fix the “room does not exist” issue. I’ll walk through what helps and what to try next. Short answer •

DeleteRoom

requires the room name (not a SID). If you used the exact room name returned by

list_rooms()

and the API still says “requested room does not exist,” a restart usually is not the first fix and often won’t resolve the underlying cause. • The right next steps are to confirm the API and UI are pointing at the same instance/cluster, inspect server logs around the time you attempt deletion, and verify there are no propagation or version mismatches. What to check now (quick steps) 1. Confirm you’re using the exact room name returned by

list_rooms()

(copy/paste). Room names are case-sensitive. 2. Ensure the API endpoint/credentials you’re calling target the same LiveKit instance that shows the room in your UI. 3. Run

list_rooms()

immediately before

delete_room()

and pass the name directly from that result to

delete_room()

to avoid any naming mismatch: ◦ If

list_rooms()

does not include the room, the server already considers it gone. 1. Check server logs when you attempt delete: ◦ Look for messages like

Room finished

,

Room removed from room store

, or any errors indicating DB/Redis connectivity or Twirp issues. 1. Verify LiveKit server version vs SDK version — mismatches can cause Twirp/protobuf incompatibilities. When a restart might help • Restarting can help if the failure is caused by a transient internal error (e.g., stuck in-memory state, lost DB/Redis connection that hasn’t recovered). • Restart is useful if logs show repeated internal errors, memory corruption, or unresolved connectivity to backing stores (Redis/Postgres). • But restarting will not help if: ◦ The room is already deleted (so API correctly reports non-existence). ◦ You’re calling the wrong server/cluster or wrong credentials. ◦ There’s a race where the room is being auto-removed by the sweeper at the same time you call delete. Recommended troubleshooting sequence 1. Run: ◦

list_rooms()

and paste the output here (or copy the exact room name shown). 1. Attempt deletion immediately after listing and capture the full error/trace. 2. Check logs at the time of deletion on the LiveKit server and paste relevant lines (room-related or Twirp errors). 3. If logs show connectivity errors to Redis or DB, try restarting the LiveKit process and then retry the delete. If logs look clean but the API still says “does not exist,” the room truly isn’t in the active store anymore. If you want, paste: • The exact room name from

list_rooms()

(copy/paste), • The delete call you run (code snippet), • The LiveKit server logs around the delete attempt, • How you deployed LiveKit (docker/helm/binary) and the server version. I’ll review those and tell you whether a restart is likely to help or what targeted fix to apply next.

is there anyway we can reset this.. like redis memory gets clearred and all the active rooms OR stale rooms gets clearred from the memory

Thanks — I understand you want a way to “reset” your self‑hosted LiveKit so stale or active rooms are cleared (for example by clearing Redis memory or restarting services). I’ll explain what’s safe, what to avoid, and the steps to take depending on your deployment. Short answer • Clearing Redis or restarting LiveKit can remove in‑memory/stale state and may resolve stuck rooms, but it has significant side effects (disconnecting participants, losing transient state). Do this only after confirming backups and during a maintenance window. • Safer first steps: use the RoomService API, verify you’re talking to the same instance/cluster, inspect logs, and attempt targeted fixes before a full reset. What happens if you clear Redis or restart LiveKit • Clearing Redis: ◦ If LiveKit is using Redis as a room store or for cluster coordination, flushing Redis will remove in‑memory records of active rooms and presence. ◦ This will likely cause LiveKit to lose knowledge of active rooms, resulting in participants being disconnected, temporary inconsistencies, or rooms appearing to vanish from the API/UI. ◦ It may resolve stale room entries that are stuck in Redis, but you will lose transient state and may need to restart services to reinitialize properly. • Restarting LiveKit: ◦ A restart can recover from transient errors, clear in‑process caches, and reestablish connections to backing stores. ◦ Restart alone does not clear persistent store entries (Postgres, persistent Redis data unless you flush it). Safer troubleshooting steps to try first 1. Confirm environment and scope ◦ Which deployment: Docker, Helm/Kubernetes, or binary? ◦ Is LiveKit clustered? Are you using Redis for clustering/room store? ◦ LiveKit server version? 1. Verify room state via API immediately before action ◦ Call

list_rooms()

and copy the exact name returned. ◦ Attempt

delete_room()

using that exact name and paste any full error output. 1. Inspect server logs ◦ Look for lines mentioning

sweeper

,

Room finished

,

Room removed from room store

, or connectivity errors to Redis/Postgres. ◦ If logs show Redis errors or repeated Twirp RPC errors, that points to backing store problems. 1. Targeted fixes (preferred) ◦ If some rooms are stuck in Redis: consider removing only the offending keys rather than flushing entire DB. This is safer and preserves other state. ◦ If you can identify the room key(s) in Redis (based on room name/ID), delete those keys and then restart the LiveKit process that owns them. ◦ If a single LiveKit node is unhealthy in a cluster, restart that node rather than all nodes. How to safely clear Redis (if you decide to) • Warning: flushing Redis will remove other cached/coordination state. Only do this in a maintenance window. 1. Back up Redis (RDB/AOF) or snapshot before making changes. 2. If you use a dedicated Redis instance for LiveKit, connect and inspect keys (do NOT immediately run FLUSHALL): ◦ Use

KEYS livekit:*

or

SCAN

to find LiveKit-related keys. 1. Remove specific room keys when possible: ◦

DEL <key1> <key2> ...

1. If you must flush everything: ◦

FLUSHDB

(flush current DB) or

FLUSHALL

(flush all DBs). 1. After cleanup, restart LiveKit processes so they reinitialize state. If you’re on Kubernetes / Helm • Restart a LiveKit pod: ◦ kubectl rollout restart deployment/<livekit-deployment> • If using Redis as a StatefulSet, perform pod restart or scale operations carefully and ensure persistence is handled. When a reset is recommended • Logs show Redis or DB corruption/unreachable. • Multiple nodes have inconsistent state and targeted deletes don’t fix it. • You’re in a controlled maintenance window and can tolerate participant disconnects. What I recommend now • Don’t flush Redis yet. First: a. Tell me your deployment (Docker/Helm/binary), LiveKit version, and whether you use Redis. b. Paste

list_rooms()

output and the exact

delete_room()

error (full text). c. Paste the relevant server log lines around the delete attempts (or tell me what you see). • With that I’ll: ◦ Show the exact Redis keys to inspect/delete if appropriate, or ◦ Provide the minimal restart commands for your deployment, or ◦ Give a step‑by‑step safe Redis flush plan if flushing is your only option. If you confirm you want the Redis flush instructions now, say so and I’ll provide the exact commands and safety checks for your environment.