https://livekit.io logo
Join Slack
Powered by
if a job is running and process gets killed then a...
# ask-ai
c
if a job is running and process gets killed then a new job is created with same room resulting in new agent joining the room
t
Thanks for reaching out, Abhishek. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
You're describing that killing a running job's process results in a new job being created for the same room and a new agent joining. I can help troubleshoot that—a few likely causes and quick checks: • Automatic dispatch rules: If your dispatch is set to auto-assign agents when a room is active or when participants reconnect, the server may re-dispatch an agent to the same room. Check your agent dispatch configuration. • Room lifetime: If the room remains active after the job process is killed, subsequent connections or dispatch logic can trigger a new job. Confirm whether your workflow deletes or closes the room when the job ends. • Client/server reconnection logic: Client-side or server-side code that retries or re-creates agent sessions on disconnect can cause a new dispatch. Search for reconnection handlers that call dispatch or create sessions. • Job lifecycle handling: The framework does not automatically recreate jobs after a process is killed. If new jobs are appearing, some external code or rules are triggering dispatch on room state changes. To help further, please tell me: 1. Do you use automatic dispatch or explicit/manual dispatch? 2. After the job process is killed, does the room stay open (participants still present) or is it left empty/active? 3. Any reconnection retries or code that listens for disconnects and requests agents? 4. If possible, share the dispatch rule or the minimal sequence that leads to the new job being created. With those details I can point to the exact setting or code path to change to prevent unintended re-joins. Sources: Job lifecycle | LiveKit docs | Agent dispatch | LiveKit docs
c
for inbound call it will be on automatic dispatch
t
Thanks — because inbound calls use automatic dispatch, that explains the behavior: when the job process is killed the room can remain active and automatic dispatch will assign another available agent to that room. What you can do next (pick one or more): • Switch to explicit dispatch by setting an 
agent_name
on your agent server so agents only join when explicitly dispatched. ◦ Example: 
@server.rtc_session(agent_name="inbound-agent")
(Python) or 
new WorkerOptions({ agentName: "inbound-agent" })
(Node). • Update your SIP dispatch rule to list specific agents in 
room_config.agents
or use tokens / API 
CreateAgentDispatchRequest
to dispatch explicitly. • Ensure rooms are closed/deleted when the job ends, or perform a graceful shutdown with 
session.shutdown()
/ 
ctx.shutdown()
so no orphaned room triggers dispatch. • Prevent unintended re-registration/restarts of the agent server which can trigger new dispatches. Would you like help changing to explicit dispatch or reviewing your SIP dispatch rule? If so, share the dispatch rule or the minimal sequence that leads to the new job being created. Sources: Agent dispatch | LiveKit docs | SIP dispatch rule | LiveKit docs | Job lifecycle | LiveKit docs
c
sorry .. i have put agent_name in dispatch rule...
t
Thanks — I see you’ve already set 
agent_name
in the dispatch rule. That’s a good step toward explicit dispatch. To help find why a new agent still joins after killing the job, please share the following so I can diagnose: 1. The SIP dispatch rule snippet (the part that includes 
agent_name
/ 
room_config.agents
). 2. Whether your agent server process restarts or re-registers after the job is killed. 3. Whether the room remains active after the job is killed (any participants or room not deleted). 4. Any relevant logs around the time the new job is created (agent dispatch events or server registration messages). If you prefer, paste just the minimal dispatch rule and a short log excerpt showing the new dispatch; I’ll point out exactly what to change.
c
"roomConfig": { "agents": [ { "agentName": "voice-stage-temp", "metadata": "{\"client_id\":\"SmaJ76_689VQE\"}" } ] }
t
Thanks — I see your dispatch rule sets 
roomConfig.agents
with 
agentName: "voice-stage-temp"
. Next steps to stop new agents joining the same room after you kill the job: 1. Ensure your agent process is configured with the same agent name so it runs in explicit-dispatch mode: ◦ Python: 
@server.rtc_session(agent_name="voice-stage-temp")
◦ Node: set 
agentName: "voice-stage-temp"
in your AgentServer/WorkerOptions 1. Confirm the agent process is not restarting or re-registering after the job is killed. If it restarts, explicit dispatch will still allow it to accept dispatched jobs. 2. Make sure the room is closed or you perform a graceful shutdown when a job ends (call 
session.shutdown()
/ 
ctx.shutdown()
), so the room doesn't remain active and trigger another dispatch. If you already have 
agent_name
set in your agent code and still see a new agent join, please paste: • The agent startup snippet showing 
agent_name
(or WorkerOptions), and • A short log around the time the job is killed and the new dispatch occurs. I’ll pinpoint the mismatch.
c
2025-12-16T071540 {"message": "process is unresponsive, killing process", "level": "ERROR", "name": "livekit.agents", "pid": 4334, "job_id": "AJ_23E9JQk99pLs", "timestamp": "2025-12-16T071540.601682+00:00"} 2025-12-16T071540 {"message": "killing process", "level": "INFO", "name": "livekit.agents", "pid": 4334, "job_id": "AJ_23E9JQk99pLs", "timestamp": "2025-12-16T071540.601980+00:00"} 2025-12-16T071602 {"message": "received job request", "level": "INFO", "name": "livekit.agents", "job_id": "AJ_23E9JQk99pLs", "dispatch_id": "AD_Z4wqtsBNapR7", "room_name": "call-_+918045685151_94V5zfDRfZBn", "agent_name": "voice-prod", "resuming": false, "timestamp": "2025-12-16T071602.356226+00:00"}
t
Thanks — the logs are the key. They show the new job was dispatched with agent_name "voice-prod" while your dispatch rule lists "voice-stage-temp". That mismatch explains why a new agent joined the room after the killed process. What to do next: • Align names: either change the dispatch rule to 
agentName: "voice-prod"
or configure your agent process to use 
agent_name="voice-stage-temp"
so explicit dispatch is honored. • After aligning, ensure the agent process isn't auto-restarting or re-registering unexpectedly and that you perform graceful shutdown (
session.shutdown()
/ 
ctx.shutdown()
) when jobs end. Please paste your agent startup snippet (where you set 
agentName
/ 
agent_name
) and I’ll confirm the exact change.
c
i gave the logs for voice-prod.. also my dispatch rule for this has agent name as voice-prod
t
Thanks — I see the logs show a new dispatch for 
agent_name: "voice-prod"
and you confirm the dispatch rule uses 
voice-prod
. That means the new agent joining is expected under explicit dispatch when a dispatch request is sent while the room still exists. Possible causes and what to check (pick applicable items): • Confirm your agent process is started with 
agent_name="voice-prod"
so it runs in explicit-dispatch mode (Python 
@server.rtc_session(agent_name="voice-prod")
or Node 
agentName: "voice-prod"
). • Check whether something is sending a new dispatch request after the process is killed (SIP gateway, re-register, or retry logic). The log line "received job request" shows a new dispatch was issued for that job_id/dispatch_id. • Verify the room remains active after the kill; if the room is still present, a subsequent dispatch will join the same room. Ensure you perform graceful shutdown (
session.shutdown()
/ 
ctx.shutdown()
) or delete/close the room when the job ends. • Ensure the agent process itself is not restarting automatically (supervisor/container restart) which could accept dispatches again. If you want, I can: • Review your agent startup snippet to confirm 
agent_name
is set correctly, or • Help inspect logs for the component issuing the dispatch (share the preceding log lines around the new dispatch). Which would you like me to do next?
c
livekit sip server maganges the dispatch for inbound
t
Thanks — since the LiveKit SIP server manages inbound dispatch, that explains why a new dispatch was issued after the agent process was killed: the SIP server detected the call/room still present and requested another agent for that room. To stop automatic re-dispatchs for this scenario, do one or more of the following: • Use explicit dispatch for inbound SIP rules (ensure the SIP dispatch rule lists the specific agent in 
roomConfig.agents
and does not rely on global automatic assignment). • Ensure the agent process is configured with the matching 
agent_name
(e.g., 
voice-prod
) so it runs in explicit-dispatch mode and only accepts dispatches targeted to it. • Prevent the SIP server from retrying dispatch on failures—check SIP gateway/retry settings so it doesn’t re-issue dispatches when an agent process is killed. • Clean up the room on job end or perform a graceful shutdown (
session.shutdown()
/ 
ctx.shutdown()
), so the room isn’t left active and retriggered for dispatch. If you’d like, I can: • Show an example SIP dispatch rule configured for explicit dispatch, or • Review the SIP server’s dispatch/retry logs (paste a short excerpt) to identify what component issued the subsequent dispatch. Which help would you prefer?
c
livekit SIP server manages the dispatch
t
You're correct — the LiveKit SIP server is performing the dispatch. That explains why killing the agent process leads to a new job: the SIP server sees the room/call still active and issues another dispatch. What you can do now (concise, pick what's applicable): • Confirm explicit dispatch in SIP rule: ensure the SIP dispatch rule lists the specific agent in 
roomConfig.agents
(you already have this). This prevents generic auto-assignment but does not stop the SIP server from re-dispatching the listed agent while the room exists. • Ensure agent runs in explicit-dispatch mode: start your agent with the matching name so it only accepts explicit dispatches. ◦ Python: 
@server.rtc_session(agent_name="voice-prod")
◦ Node: set 
agentName: "voice-prod"
in AgentServer/WorkerOptions • Prevent SIP retry/re-dispatch: check SIP gateway/retry settings so the SIP server does not re-issue dispatches when an agent is killed or becomes unresponsive. • Clean up the room / graceful shutdown: when a job is terminated, call 
session.shutdown()
/ 
ctx.shutdown()
or delete/close the room so the SIP server does not see an active room to re-dispatch against. If you want, I can: • Show a minimal example SIP dispatch rule for explicit dispatch, or • Inspect the SIP dispatch/retry logs if you paste the log lines around the dispatch request (especially entries preceding "received job request"). Which would you like me to help with?
9 Views
Open in Slack
PreviousNext
Powered by