https://livekit.io logo
Join Slack
Powered by
the user clicked end meeting in next js, the meeti...
# ask-ai
s
the user clicked end meeting in next js, the meeting has ai agent, human, and recording, what is the gracefull ending that i should do, to clean up the human browser resorces and to end the room gracefully ?
t
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.
Thanks — I understand you want a graceful shutdown flow in Next.js that frees the human browser resources, stops recording, and removes the AI agent cleanly. Here’s a concise, safe sequence to follow. 1) Frontend — disconnect the human client • Call 
await room.disconnect()
in the browser. This unpublishes local tracks, unsubscribes from remote tracks, and releases media devices and WebAudio contexts. • After disconnect completes, clear any room/participant state and unmount components tied to the room to drop React references and avoid leaks. 2) Backend — end the room and stop egress/agents • From your server, call the Room deletion API to force the room to end (for example, 
RoomServiceClient.deleteRoom(roomName)
using the server SDK). This causes remaining participants (AI agent) and egress/recording to be terminated server-side and ensures recordings stop cleanly. • If your AI agent runs as a separate job/process, ensure it listens for the room-deleted event or you invoke its shutdown hook so it can save state and exit. 3) Optional but recommended • If you start recordings/egress separately, explicitly stop egress before or when deleting the room to ensure finalization of recording files. • Ensure any agent-side shutdown callbacks run (e.g., save logs, close DB connections). • Return a short “meeting ended” acknowledgement to the UI once both client disconnect and room deletion succeed. Minimal sequence to implement 1. Frontend: 
await room.disconnect()
→ cleanup UI/state. 2. Backend: call 
deleteRoom(roomName)
→ stops AI agent and recording. If you want, tell me: • which LiveKit SDK you’re using on the server (Node/TS, other), and • whether your AI agent is a separate process or a LiveKit server-side job— and I’ll give exact code snippets for both the frontend and server steps. Sources: Job lifecycle | LiveKit docs | Stream music over WebRTC using React and WebAudio
s
what about this sequence await room.disconnect() then backend 1- stop recording 2- deleteRoom(roomName)
t
Yes — that sequence is correct and safe. Recommended order and why: • Frontend: 
await room.disconnect()
— frees the human’s media tracks, unsubscribes from remote tracks, and clears browser audio/WebRTC resources immediately. • Backend: 1) stop recording/egress — ensures the recording is finalized and files are properly closed. 2) 
deleteRoom(roomName)
— forces remaining participants (AI agent) out and tears down the room/server-side resources. Notes and small precautions: • Stopping egress before deleting the room ensures the recording finalizes cleanly; deleting the room first can still stop egress, but explicit stop avoids partial or delayed finalization. • Return success from each step to the client so the UI can show a definitive “ended” state (disconnect confirmed → egress stopped → room deleted). • If your AI agent needs time to save state, have it listen for room-deleted events or run a shutdown hook so it can finish work before exit. If you want, I can provide example Node/TS snippets for stopping egress and calling 
deleteRoom
. Which server SDK are you using?
s
• Stopping egress before deleting the room ensures the recording finalizes cleanly; deleting the room first can still stop egress, but explicit stop avoids partial or delayed finalization. explain more, what is consequences of calling room delete without stop recording
t
Good question — here’s what happens and why explicitly stopping egress first is safer. What DeleteRoom does to recordings • Deleting the room forcibly disconnects all participants, including the egress/recording participant. That disconnection causes the recording to stop as a side effect. • Because the egress is stopped by abrupt disconnection rather than a dedicated stop command, the recording may not be muxed/finalized/uploaded as cleanly or promptly. Concrete consequences of deleting without StopEgress • Potentially incomplete or corrupted final file: the egress may be interrupted mid-chunk or mid-upload, increasing risk of a partial output. • Slower availability: finalization and upload can be delayed while the egress worker detects the disconnect and performs cleanup. • Less predictable resource cleanup: egress-specific resources (muxers, headless browser instances, uploads) may be cleaned up less gracefully. • Harder error handling and retry: you have less control or explicit status about successful finalization and upload, making retries or troubleshooting more difficult. Recommended safe sequence 1. Frontend: 
await room.disconnect()
— free browser media and UI state. 2. Backend: call 
StopEgress
(explicit stop) — ensure the recording is muxed and uploaded cleanly. 3. Backend: call 
DeleteRoom(roomName)
— tear down the room and force remaining participants out. Notes • Stopping egress first gives you a clear success/failure response to act on (e.g., retry on failure). • If your workflow cannot call StopEgress (rare), DeleteRoom will still stop recording but accept the increased risk above. • If you want, I can provide Node/TS snippets for calling StopEgress and DeleteRoom for your server SDK. Which SDK are you using? Sources: Job lifecycle | LiveKit docs | Universal Egress | server-sdk-js | livekit/livekit_composite | DeepWiki | Server-side | livekit/livekit_composite | DeepWiki
3 Views
Open in Slack
PreviousNext
Powered by