help me understand this log:
```{"message": "live...
# ask-aib
brash-lamp-29679
02/20/2026, 4:35 PMhelp me understand this log:
Copy code
{
"message": "livekit::rtc_engine:782:livekit::rtc_engine - resuming connection failed: signal failure: server sent leave during reconnect: reason=StateMismatch, action=Reconnect",
"level": "ERROR",
"name": "livekit",
"pid": 5311,
"job_id": "AJ_8NXhn4kHzEFT",
"timestamp": "2026-02-19T01:06:34.024760+00:00"
}t
tall-airline-16756
02/20/2026, 4:35 PMThanks for reaching out, Jacob. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
tall-airline-16756
02/20/2026, 4:35 PMThanks — I’m looking at the error log you pasted. I’ll explain what it means, why it happens, and what you can check next.
Acknowledging the log
• The log shows a reconnection attempt failed with: "server sent leave during reconnect: reason=StateMismatch, action=Reconnect". This means the client tried to resume after a disconnect but the server rejected the resume and forced a leave citing a StateMismatch.
What StateMismatch means (short)
• StateMismatch means the server and the client disagree about the participant’s session state. The server decided the client’s previous session was no longer valid (e.g., cleaned up due to timeout or unclean disconnect), so it responded with a Leave instead of resuming the session.
Typical causes
• Unclean disconnects (app crash, abrupt tab/window close) so the client didn’t notify the server it was leaving.
• Long reconnection delay (server times out and removes session; reconnection after ~20s may fail).
• Network blackouts where the client can’t get keep-alives to the server.
• Client restarted in a way that left server-side state inconsistent (different tracks/subscriptions than server expects).
Why the server sends Leave during reconnect
• The server sees the reconnect attempt but detects the client’s expected state doesn’t match server state (tracks, subscriptions, or peer connection state). Rather than resume, it tells the client to leave so the client can rejoin cleanly.
What to check now (practical steps)
• Confirm how long the client was offline before the reconnect attempt. If > ~20s, the server may have timed out the session.
• Verify the client is calling proper cleanup on intended disconnects (e.g.,
room.disconnect()b
brash-lamp-29679
02/24/2026, 12:05 AMI would I handle reconnection logic, is that not already built into the agent?
t
tall-airline-16756
02/24/2026, 12:06 AMThanks — I’ll explain this part of your question: whether you need to implement reconnection logic yourself, or if the LiveKit agent already handles it.
Short answer
• Reconnection is handled automatically by the LiveKit agent/client. You generally do not need to implement low-level reconnect logic yourself.
• You may want to add higher-level application behavior (timeouts, retries for job-specific actions, or a clean rejoin flow) depending on your needs.
What the agent and SDK handle for you
• Automatic reconnection with exponential backoff when a network interruption happens. The agent will try to re-establish its WebSocket / WebRTC connections and resume session state when possible.
• AgentSession / agent framework will attempt to recover the session and resume tracks/participant state without you managing raw WebSocket or PeerConnection reconnections.
Why you still saw StateMismatch
• The agent’s reconnection attempts can fail if the server has already cleaned up the session (for example, after ~20 seconds with no keep-alives) or if the server and client state differ. In that case the server sends a Leave with reason=StateMismatch and the client must perform a fresh join.
When to add custom logic
• Implement app-level handling for these cases:
◦ Treat a server Leave during reconnect as a signal to perform a clean rejoin (create new room connection / new auth token).
◦ Detect prolonged offline periods and trigger a fresh join instead of repeated resume attempts.
◦ Graceful disconnects: call your SDK’s disconnect/cleanup on intentional user exits so server state stays consistent.
◦ Job-level retries (e.g., resend greeting prompts) or end the job after N failed reconnects.
◦ Silence/inactivity detection and timeouts (if you want to free resources or reassign jobs).
How I can help next
• Tell me which SDK/platform you’re using (Web, Node, iOS, Android, or the Agents server). I’ll give concrete code snippets or recommended patterns for:
◦ Handling a server Leave with reason=StateMismatch.
◦ Implementing a clean rejoin flow.
◦ Adding sensible retry/timeouts around agent jobs.
• If you want, share the client-side logs around the disconnect timestamp and I’ll point out whether it looks like an abrupt crash, a network blackout, or a prolonged reconnection attempt.
Which platform should I tailor examples for?
Sources: client-sdk-swift | livekit/livekit_composite | DeepWiki | Server lifecycle | LiveKit Documentation | How to detect and handle silence during calls | LiveKit | Job lifecycle | LiveKit Documentation | How to implement call greeting retries in voice agents | LiveKit
b
brash-lamp-29679
02/24/2026, 12:11 AMwhy did it not work in this case?
t
tall-airline-16756
02/24/2026, 12:12 AMThanks — I understand you expected the agent’s built-in reconnection to resume the session but instead got a StateMismatch and a Leave. To tell you exactly why it failed in this case I need a little more context. Below I list the most useful diagnostics and some likely explanations so you can quickly check what happened.
What I need from you
• Which SDK/platform was the agent using? (Web, Node.js, iOS, Android, or the Agents server)
• Client-side logs around the same timestamp (±30s) where the error occurred — especially any WebSocket, ICE, or PeerConnection messages.
• How long was the client offline before it tried to reconnect? (even an approximate duration is helpful)
• Was the disconnect expected (user closed app) or abrupt (crash, network outage)?
• Are you using TURN servers? Any recent changes to network or TURN configuration?
• If this is an agent job, did another agent pick up the job after this disconnect?
Quick likely causes to check right now
• Long offline period: If the client was offline for ~20+ seconds, the server may have cleaned up session state and refused to resume, causing StateMismatch.
• Abrupt/unclean disconnect: App crash or force quit prevented a proper leave call; the server removed the participant and rejected the reconnect.
• State changed on server side: The server-side session was altered (tracks removed, job reassigned) while the client was offline, so the client’s expected state no longer matched.
• Network/ICE/TURN failure: The agent’s reconnection attempts may have failed to re-establish the WebRTC peer connection due to blocked ports or missing TURN reachability; the server then timed out.
• Duplicate or stale credentials/tokens: If the reconnect used an invalid or stale token, the server might refuse resume and force a leave.
Immediate things you can inspect or try
• Correlate timestamps: match client logs (disconnect/reconnect attempts) to the server log timestamp you sent.
• Look for an abrupt process exit or exception in the client logs right before the disconnect.
• Check if TURN was reachable from the client at the time (connection-test or client-side ICE logs).
• If you can reproduce: simulate a brief (<10s) disconnect and a long (>30s) disconnect to see different server behaviors.
• If this is job-related, check whether the job was reassigned or timed out on the server during the outage.
How I can help next
• Share the platform and the relevant client logs and I’ll point to the exact failure cause and a specific remediation path.
• I can provide code examples for handling a server Leave with reason=StateMismatch (clean rejoin flow) for your SDK.
• I can suggest app-level retry/timeouts and logging best practices to avoid this silently happening again.
Which SDK/platform and client logs can you share?
2 Views