what is the livekit behaviour when i delete the room using roomService.deleteRoom() will it try to retry creating the room instance with same name again or once it is deleted means it is deleted ?

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

even if we delete the room with roomservice.deleteroom , that time also new join request happends ?? and new session with the same roomname is created is that expected ?

You're right to check—good question. • If

deleteRoom()

is called, the room is terminated and removed. However, if your system (or clients) allow auto-creation on join (a

createRoom

-on-join flow), a subsequent join request can immediately create a new session with the same room name. That behavior is expected when join requests trigger room creation. • There is also a race condition: if a join arrives right around the time

deleteRoom()

runs, the new room may be created immediately and could even reuse the previous Room ID due to timing. This is not a retry by LiveKit — it's a result of overlapping operations. Recommendations to avoid unexpected recreation: • Require explicit room creation (disable auto-create on join), or • Use unique room names (append timestamp/UUID), or • Coordinate deletion and joins (e.g., mark room as closed before deleting). Which approach would you prefer or how do you currently create rooms on join? , with interactive elements

thing is if am deleting the room using roomservice.delete room then automatic new join request which is causing for new session creation with the same room name shouln't happended

You're right to expect deletion to stop the session — thanks for calling this out. Deleting with

roomService.deleteRoom()

terminates that room instance, but LiveKit will recreate a room if a new join request (or a token) for that room name arrives. This automatic create-on-join behavior is expected and not a LiveKit retry of the deleted room; it’s just that a join can trigger a new room instance (and, briefly after deletion, there can be race/timing that may reuse the previous Room ID). To prevent automatic recreation, you can: • Stop issuing or accept tokens that reference the deleted room name. • Disable or avoid “create-on-join” logic in your app (require explicit

createRoom()

before allowing joins). • Use unique room names per session (e.g., append timestamp or UUID). • Add an app-level block: mark the room name as closed/deleted in your service and reject join attempts until you allow recreation. Which option fits your setup best, or can you share how joins and tokens are currently issued so I can suggest a concrete change? Sources: Avoiding Room ID Reuse When Re-Creating Rooms With the Same Name | CreateRoom() is Taking Too Long, with interactive elements

how can i do this Stop issuing or accept tokens that reference the deleted room name.

You're asking how to stop tokens that reference a deleted room so it can't be auto-recreated — good call. Here are concise, actionable steps you can implement. 1) Prevent token issuance for deleted rooms (backend) • Maintain room state in your database (active, deleted/closed). • Before signing/returning a LiveKit token, check room status; if marked deleted, reject the token request. • Example check (pseudocode):

if room_status(room_name) == "deleted":
    raise Error("room is deleted")
# otherwise create token with `video.room` = room_name

2) Shorten token lifetime and avoid client reuse • Issue tokens with short TTLs so stale tokens expire quickly. • Clear client-side cached tokens when a room ends (localStorage/sessionStorage). 3) Revoke or rotate server secrets (if urgent) • If tokens were already issued and could be reused before expiry, rotate the key that signs tokens to invalidate existing tokens immediately. 4) Add an application-level blocklist or gating • Add a denylist of recently deleted room names and check it on join/token request. • Optionally mark a room as “closed” before calling

deleteRoom()

to give your system time to stop issuing tokens. 5) (Optional) Use webhooks to sync state • Use LiveKit webhooks (room_started/room_finished) to update your backend room status automatically so token issuance logic stays accurate. If you share how tokens are currently generated (language/framework) or whether you use short TTLs or cached tokens on clients, I can give a specific code example for your stack. Sources: Troubleshooting 401 Unauthorized and Token Errors | LiveKit | Avoiding Room ID Reuse When Re-Creating Rooms With the Same Name, with interactive elements

instead of fixing here To prevent automatic recreation, you can: • Stop issuing or accept tokens that reference the deleted room name. • Disable or avoid “create-on-join” logic in your app (require explicit

createRoom()

before allowing joins). • Use unique room names per session (e.g., append timestamp or UUID). • Add an app-level block: mark the room name as closed/deleted in your service and reject join attempts until you allow recreation. why the react-agent-starter applicaiton is trying to rejoin in the deleted room ? how can we prevent from there ?

Thanks — I hear you: you want to stop the react-agent-starter client from trying to rejoin a room after you call

roomService.deleteRoom()

. Short answer: the client is attempting to reconnect (or reuse a token) — not because LiveKit auto-retries deletion, but because the react-agent-starter Session/TokenSource logic is still trying to connect. To stop it, do one or more of the following: • Call

session.end()

on the client when you delete the room. This stops the Session API’s reconnection attempts. • Ensure the frontend clears any cached token and the room name from state/context after deletion (no localStorage/sessionStorage reuse). • Add a server check in your token endpoint so it will refuse to issue tokens for that room name (denylist or room status check). If the client requests a token and the server rejects it, the client cannot rejoin. • Add client-side guard in TokenSource (custom token provider) to throw if the room is marked deleted:

const tokenSource = TokenSource.custom(async (opts) => {
    if (await isRoomDeleted(opts.roomName)) throw new Error("room deleted");
    return fetchToken(opts);
  });

• Optionally mark the room as “closed” in your app before calling

deleteRoom()

so your backend can stop issuing tokens immediately. If you tell me where your token logic lives (which file/endpoint) or which reconnection path your client uses, I can give a concrete code change for react-agent-starter. Sources: Build agent experiences faster with Session APIs | LiveKit | Avoiding Room ID Reuse When Re-Creating Rooms With the Same Name | Job lifecycle | LiveKit Documentation, with interactive elements

calling roomDelete the client app is considering it as a network drop so it trying to rejoin the room so new join request sent and new room is being created again, instead of that can i remove participant so if all participants let livekit internally terminates the room right ?

Good question — yes, removing participants is a cleaner way to avoid the client thinking the server disconnected and immediately trying to rejoin. Quick facts and recommended approach: • If you remove/disconnect all participants (via

roomService.disconnectParticipant()

or the participant

disconnect()

method), LiveKit will terminate the room naturally after the idle timeout rather than treating it as an abrupt server-side termination. This avoids the client-style “network drop” reconnection loop you’re seeing with

deleteRoom()

. • Default idle timeout is short (around 30s); you can configure

maxIdleTime

if you want a different behavior for your deployment. • Still do these on the client and server together: ◦ Call

session.end()

or otherwise stop reconnection attempts in the client when you initiate disconnects so it won’t try to rejoin. ◦ Stop issuing tokens for that room name (or check room state in your token endpoint) so stale client tokens can’t recreate the room. When to prefer each method: • Use participant disconnects → when you want a graceful end and to avoid client reconnect loops. • Use

deleteRoom()

→ when you need immediate termination and don’t mind coordinating token/client behavior to prevent recreation. Want a small code snippet for disconnecting participants or for calling

session.end()

in react-agent-starter? Which language/file should I target? , with interactive elements

even after removing participants also it is same beaviour

Thanks — I understand the frustration. Removing participants alone doesn’t stop the client from trying to rejoin because the reconnection is client-side behavior driven by an available token and the Session/TokenSource logic in react-agent-starter. What’s happening • The client sees the disconnect (whether participants were removed or server deleted the room) as a connection loss and the Session API attempts to reconnect using the same room name and token. • If a token or token endpoint still supplies a token for that room name, the join will succeed and a new room is created (auto-create-on-join). What to do (apply both server and client changes) • Stop the client’s reconnect loop: ◦ Call

session.end()

(or stop the Session reconnection) immediately when you intend the session to be finished. ◦ Ensure the client clears any cached token and room name after ending the session. • Prevent tokens for the deleted/closed room: ◦ On your token endpoint, check room state and refuse to issue tokens for deleted/closed room names (denylist or room status). ◦ Shorten token TTLs so stale tokens can’t be reused. • Block auto-create-on-join: ◦ If your server supports it, return an error or do not provide create-on-join tokens. Alternatively, require explicit

createRoom()

on the server before allowing joins. • Coordinated flow suggestion: a. Mark room as “closing” in your backend. b. Stop issuing tokens for that room. c. Instruct clients to call

session.end()

and clear tokens. d. Optionally call

disconnectParticipant()

for each participant, then

deleteRoom()

once clients are stopped. • Optional: add a short denylist window (in-memory DB) for recently-deleted names to reject token requests for a few minutes after deletion. Quick code hints • Client: call session end

// react-agent-starter
  session?.end(); // stops reconnect attempts
  clearTokenFromStorage();

• Server: deny tokens for deleted rooms (pseudocode)

if (isRoomDeleted(roomName)) return 403;
  return createToken(roomName);

If you want, tell me: • where your token endpoint is implemented (language/file), and • whether the client uses TokenSource.sandboxTokenServer or a custom TokenSource — and I’ll give a precise code patch for that stack. , with interactive elements