Can i start a room with the same id again? What happens if the the room ended and what if in progress?

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

Edge case, is it possible to happen? The user was in the room internet interrupted, all agents and recording left, the user online and joined again, can that happen from the frontend? Without calling create or start room from the api ? If yes the agent will join again and the recording?

Thanks — good, detailed scenario. I’ll address the three parts you asked about: whether the edge case can happen, whether the frontend alone can cause it, and what happens to agents and recording. • Can the edge case happen? ◦ Yes. If the room fully ends (every participant left and the departure timeout expired or the room was deleted), recreating a room with the same name can — in rare timing/race conditions — result in reuse of the previous Room ID. That edge case is possible though uncommon. • Can the frontend (without an explicit create/start API call) cause a new room to be created after an internet interruption? ◦ Yes. When a client reconnects or calls join via the LiveKit client SDK, the SDK will attempt to join the room name provided. If the original room still exists, the user rejoins that same session. If the original room has already ended, the join operation will create a new room with that name implicitly (you do not need a separate CreateRoom API call from the frontend). That is how the SDK behaves. • What happens to agents and recording? ◦ If the original room never fully ended (still within timeout), agents and recording that remain will see the user rejoin the same session. ◦ If the original room ended and the join created a new room instance, agents and recording are not automatically carried over — they would be in the old session and would need to join the new room. The new room will get a new recording session (and typically a new Room ID), except in the rare race condition where the previous Room ID is reused. Recommendation: to avoid unintended new rooms and recordings after disconnects, either • Use unique room names per logical session (append timestamp/random suffix), or • Implement reconnection logic on the server side to detect transient disconnects and prevent immediate room deletion/recreation (for example, increase departure timeout or gate automatic room creation behind a server check). If you want, tell me: • how you generate room names (server or client), and • what your departure timeout is set to, and I’ll suggest a concrete approach for your flow.

Server generation, my point the egress left, and then joined again and overtired the recording

Thanks — this is helpful context. I’ll respond to the exact points you raised about server-generated room names, egress leaving, and reconnect behavior. • If the room is still alive (not fully ended), a user who reconnects will rejoin the same room. Since you generate names on the server, the SDK’s join uses that name and will connect to the active session. • If the egress (recording) participant left while other participants remained, the room stays alive. The recording does NOT automatically resume when the user rejoins — you must restart the egress/recording yourself. • If the room fully ended (every participant left and the departure timeout elapsed), a reconnect/join call will create a new room with that name. That new room gets a new recording session; the previous recording cannot be continued. A rare race condition can sometimes reuse the old Room ID if recreation happens immediately after deletion, but this is uncommon. • To avoid unintended new rooms/recordings: ◦ Increase the departure timeout so transient disconnects don’t end the room. ◦ Keep server-side control of room creation and egress: on reconnect, verify room state before automatically restarting recording. ◦ Or use unique room names per logical session (timestamp/suffix) to guarantee distinct rooms. Tell me your current departure timeout and whether your server auto-starts egress on join — I’ll suggest the exact changes to prevent recording overtakes.

How can i use timestamps and suffex, my point happens it uses the same name from the front, didn't call the api to get the new name, and the room was ended and all left but after a second the use rejoined and livekit used the same room again

Thanks — I hear you: the frontend reused the same name, the room ended, the user rejoined a second later, and LiveKit reused the previous room/egress. That’s possible and caused the recording to be overtaken. Here’s exactly what to do to prevent it. 1) Why it happened (short) • If a new join happens before LiveKit’s background cleanup finishes, LiveKit can reuse the previous Room ID even for the same name. That can make recording/egress appear to continue on the “new” session. 2) Quick server-side fixes (recommended) • Always generate a unique room name on the server for each logical session. Append a timestamp or UUID so a reconnect can’t accidentally reuse the exact name. ◦ Example patterns: ▪︎

meeting_${Date.now()}

▪︎

meeting_${new Date().toISOString().replace(/[:.]/g,'-')}

▪︎

meeting_${uuidv4()}

• On reconnect, require the client to request the current room name/token from your server instead of reusing a cached name in the frontend. 3) Additional protections • Increase departure timeout so brief disconnects don’t fully end the room. • Do not auto-restart egress automatically on any join. Gate egress start behind a server check that ensures this is a deliberate new session. • Optionally, explicitly call DeleteRoom when you want to end a session and only allow new rooms after the server confirms deletion. 4) Concrete client flow to implement 1. Client loses connection. 2. Client asks your server for a room name / join token when reconnecting. 3. Server checks whether the previous session should be resumed or a new session created. ◦ If resume: return the active room name/token. ◦ If new session: create a unique room name (timestamp/UUID), return that. 1. Client joins using the returned name/token. If you want, tell me: • which server language/framework you use and whether you currently cache room names in the frontend — I’ll give a one-click code snippet for generating/returning unique names and the reconnection flow. Sources: Avoiding Room ID Reuse When Re-Creating Rooms With the Same Name | sip | livekit/livekit_composite | DeepWiki

So there is event in the front for reconnect ? We use next js

Yes — the LiveKit client emits connection-state events you can use in the frontend to detect disconnects and reconnects. Below is a concise Next.js-friendly approach and key best practices to avoid reusing room names or restarting egress accidentally. What to listen for • Use the Room SDK events: ◦

connectionStateChanged

(recommended) — gives states: "connected", "disconnected", "reconnecting", "reconnected". ◦ You can also use

room.on('participantDisconnected')

/

participantConnected

for participant-level events. Next.js / React pattern (useEffect) • When mounting your component, attach a handler for

connectionStateChanged

. • On reconnect or when going from "disconnected" to "reconnecting"/"reconnected", request a fresh join token/room name from your server instead of reusing any cached name. Minimal example (React / Next.js)

import { useEffect } from 'react';
import { Room } from 'livekit-client';

function LiveRoom({ room }: { room: Room }) {
  useEffect(() => {
    const onState = (state: string) => {
      if (state === 'reconnecting') {
        // show UI that we're reconnecting
      }
      if (state === 'reconnected') {
        // before rejoining or resuming flows, request token/room info from server
        // fetch('/api/join', { method: 'POST', body: JSON.stringify({ resume: true }) })
        // use returned token to ensure server decides resume vs new room
      }
      if (state === 'disconnected') {
        // treat as left — UI + server-driven decision to create new room if needed
      }
    };

    room.on('connectionStateChanged', onState);
    return () => { room.off('connectionStateChanged', onState); };
  }, [room]);

  return null;
}

Server-driven token + naming policy (must) • On any reconnect attempt, have the client call your server for a fresh join token and room name. • Server checks whether to resume the previous session (still active) or to create a new unique room name (append timestamp/UUID) and issues a token for that room. • This prevents the frontend from reusing an old static name and avoids accidental egress restarts. Additional tips • Increase departure timeout if you expect short interruptions. • Do not auto-start egress on client-only join; require a server confirmation that this is a new session. • Cache minimal state in frontend (e.g., last room id) but always validate with server before acting. If you want, tell me whether you use server-side sessions in Next.js API routes or an external API service and I’ll provide a small server snippet (Node/Express or Next.js API route) that returns a resume-or-new token and generates a timestamped room name.

What is the percentage of the edge case i mentioned can happen?

Short answer: it can happen, and in rapid recreate scenarios the chance is non-trivial — roughly 10–40% if you recreate the same name within ~30–60s. Waiting 1–2 minutes or using unique names drops the chance to near 0%. Quick rationale: • Delete/auto-close isn’t instantly cleaned across all systems; if a Create/Join with the same name happens before cleanup, the previous Room ID can be reused. • This race is more likely with immediate reuse, no explicit DeleteRoom, multi-region replication, or DB write/read lag. Concrete mitigations (pick 1–2 to implement now) • Generate unique room names server-side (timestamp or UUID): e.g.

meeting_${Date.now()}

or

meeting_${crypto.randomUUID()}

. • Require the client to request a join token/room name from your server on every reconnect (don’t let frontend reuse cached name). • Increase departure timeout so short disconnects don’t end the room. • Explicitly call DeleteRoom when ending a session and wait ~1–2 minutes before allowing reuse (not recommended vs unique names). • Gate egress start on the server (only start recording after server confirms this is a deliberate new session). If you want, I can give a Next.js API route and React snippet that: 1) requests a fresh join token on reconnect, and 2) generates timestamped/UUID room names server-side. Which would you prefer: timestamp or UUID? Sources: Avoiding Room ID Reuse When Re-Creating Rooms With the Same Name