in the python client sdk, when we lose internet, the client tries to reconnect like 10 times in a really long span, is there a way to customize this behaviour? like if we know we definitely lost connection, we don't need to keep retrying

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

i've checked and RoomEvent.RECONNECTING is only received once so i can't use that but calling room.disconnect offline will raise right?

Thanks — I see you tried

RoomEvent.RECONNECTING

and it fires only once, and you’re asking whether calling

room.disconnect()

while offline will raise. You can safely call

room.disconnect()

when offline — it will not raise an error. It gracefully cleans up the client state regardless of connection status. Since

RECONNECTING

only fires once, try one of these approaches to limit retries: • Listen for

RoomEvent.DISCONNECTED

and manage a retry counter or timer in your app; call

room.connect(...)

only when you want to retry. • If you detect definitive network loss (OS event or your own ping check), call

await room.disconnect()

to stop the SDK’s automatic reconnection. • Wrap your logic: on the first

RECONNECTING

event start a background retry loop (with your own backoff and max attempts); if you hit the limit, call

await room.disconnect()

. Would you like a concise code example for any of those patterns (retry-counter on DISCONNECTED, or a background retry loop started from RECONNECTING)? Sources: Connecting to LiveKit | LiveKit docs

yes please

Below are two concise Python examples you can use with the LiveKit client to limit reconnection attempts. 1) Retry counter using RoomEvent.DISCONNECTED (only reconnect when under max attempts)

import asyncio
from livekit import Room
from livekit.events import RoomEvent

async def connect_with_limit(url, token, max_retries=3):
    room = Room()
    retries = 0
    connecting = False

    async def on_disconnected():
        nonlocal retries, connecting
        if connecting:
            return
        retries += 1
        print(f"DISCONNECTED (count={retries})")
        if retries <= max_retries:
            connecting = True
            await asyncio.sleep(2 ** retries)  # simple backoff
            try:
                await room.connect(url, token)
            finally:
                connecting = False
        else:
            print("Max retries reached. Not reconnecting.")

    room.on(RoomEvent.DISCONNECTED, lambda _: asyncio.create_task(on_disconnected()))

    try:
        await room.connect(url, token)
    except Exception as e:
        print("Initial connect failed:", e)

    return room

2) Background retry loop started from RoomEvent.RECONNECTING (stop loop by calling room.disconnect())

import asyncio
from livekit import Room
from livekit.events import RoomEvent

async def connect_with_background_retries(url, token, max_retries=3):
    room = Room()
    retry_task = None

    async def retry_loop():
        attempts = 0
        while attempts < max_retries:
            attempts += 1
            print(f"Retry attempt {attempts}/{max_retries}")
            await asyncio.sleep(min(30, 2 ** attempts))  # backoff cap
            if room.is_connected:
                print("Reconnected during wait; stopping retries.")
                return
            try:
                await room.connect(url, token)
                print("Reconnected successfully.")
                return
            except Exception:
                print("Retry failed.")
        print("Max retries reached; calling disconnect to stop SDK reconnection.")
        await room.disconnect()

    def on_reconnecting():
        nonlocal retry_task
        if retry_task is None or retry_task.done():
            retry_task = asyncio.create_task(retry_loop())

    room.on(RoomEvent.RECONNECTING, lambda _: on_reconnecting())

    try:
        await room.connect(url, token)
    except Exception as e:
        print("Initial connect failed:", e)

    return room

Notes: • Calling

await room.disconnect()

while offline is safe and will not raise; it stops SDK reconnection attempts. • Choose the DISCONNECTED pattern if you want reconnection only after full disconnects; choose the RECONNECTING pattern if you want a background loop to attempt reconnects with full control. Want a trimmed example tailored to your app structure or an explanation of any line?

but im not getting multople events, im seeing the protocol reconnection attempts only but without event:

[DEVICE] 2025-12-18 01:53:07,165 - livekit - ERROR - livekit::rtc_engine::rtc_session:1032:livekit::rtc_engine::rtc_session - Publisher pc state failed
[DEVICE] 2025-12-18 01:53:07,165 - livekit - WARNING - livekit::rtc_engine:470:livekit::rtc_engine - received session close: "pc_state failed" UnknownReason Resume
[DEVICE] 2025-12-18 01:53:08,177 - livekit - ERROR - livekit::rtc_engine:768:livekit::rtc_engine - resuming connection failed: signal failure: ws failure: IO error: failed to lookup address information: nodename nor servname provided, or not known
[DEVICE] 2025-12-18 01:53:08,178 - livekit - ERROR - livekit::rtc_engine:766:livekit::rtc_engine - resuming connection... attempt: 1
[DEVICE] 2025-12-18 01:53:08,178 - livekit - INFO - livekit_api::signal_client::signal_stream:92:livekit_api::signal_client::signal_stream - connecting to <wss://project.livekit.cloud/rtc?sdk=python&protocol=16&auto_subscribe=1&adaptive_stream=0&version=1.0.18&reconnect=1&sid=>

Thanks — that log matches what you described. • Those "resuming connection... attempt: N" messages come from the underlying protocol layer (Rust/WebRTC) and do not emit repeated SDK events.

RoomEvent.RECONNECTING

is only fired once when reconnection begins, so you won't see an event per internal attempt. • You can safely stop those internal retries by calling

await room.disconnect()

even while offline; it will not raise and will cancel the SDK's background reconnection attempts. Suggested practical approach (short): • On the single

RECONNECTING

event, start your own timer/loop (e.g., timeout or max-duration). • If you hit your limit (time or attempts) call

await room.disconnect()

to halt the internal retries. • Optionally, use an external network check (ping/DNS) to decide earlier to call

disconnect()

. Would you like a tiny code snippet implementing a timeout-based stop that triggers from

RECONNECTING

? Sources: Connecting to LiveKit | LiveKit docs | server-sdk-go | livekit/livekit_composite | DeepWiki | Subscribing to tracks | LiveKit docs | client-sdk-android | livekit/livekit_composite | DeepWiki | How We Built a Globally Distributed WebRTC Mesh Network

okay that makes sense, can you show me a snippet?

Below is a concise Python snippet that starts a timeout when

RECONNECTING

is received and calls

await room.disconnect()

if the timeout elapses, stopping the SDK's internal reconnection attempts. Calling

disconnect()

while offline is safe and will not raise.

import asyncio
from livekit import Room
from livekit.events import RoomEvent

RECONNECT_TIMEOUT = 30  # seconds until we force disconnect

async def connect_with_reconnect_timeout(url, token):
    room = Room()
    reconnect_task = None

    async def force_disconnect_after_delay(delay):
        await asyncio.sleep(delay)
        if not room.is_connected:
            print(f"No reconnect after {delay}s — forcing disconnect.")
            await room.disconnect()  # safe to call offline

    def on_reconnecting(_evt=None):
        nonlocal reconnect_task
        # If a previous task exists, cancel and restart the timeout
        if reconnect_task and not reconnect_task.done():
            reconnect_task.cancel()
        reconnect_task = asyncio.create_task(force_disconnect_after_delay(RECONNECT_TIMEOUT))
        print("RECONNECTING: started timeout to force disconnect")

    def on_reconnected(_evt=None):
        nonlocal reconnect_task
        if reconnect_task and not reconnect_task.done():
            reconnect_task.cancel()
            print("RECONNECTED: canceled force-disconnect timeout")

    room.on(RoomEvent.RECONNECTING, lambda evt=None: on_reconnecting(evt))
    room.on(RoomEvent.RECONNECTED, lambda evt=None: on_reconnected(evt))

    try:
        await room.connect(url, token)
    except Exception as e:
        print("Initial connect failed:", e)

    return room

If you prefer a max-attempts approach instead of a timeout, I can provide that variant. Would you like it?

when the Agent reconnectes successfully (or us) and we receive a "reconnected" event, do we need to re-publish and re-subscribe to their tracks?

You do not need to re-publish or re-subscribe after a successful reconnection. • Local published tracks are automatically re-published when the client reconnects (you’ll see the corresponding published events). • Remote subscriptions are restored automatically (with

autoSubscribe

on by default); the SDK attempts to recover prior subscription state. • Use

RECONNECTING

/

RECONNECTED

events only for UI/UX or cleanup (e.g., show a reconnecting banner, or cancel a reconnect timeout). Don’t re-publish/re-subscribe manually unless you have custom logic that requires it. Sources: Connecting to LiveKit | LiveKit docs | Subscribing to tracks | LiveKit docs | Job lifecycle | LiveKit docs

is there any opportunity in which on RECONNECTED, there won't be an agent in the room?

Yes — it's possible the agent won't be in the room when you get

RECONNECTED

.

RECONNECTED

only means your client restored signaling/media; it does not guarantee any particular participant is still present. Common reasons an agent might be absent at that point: • The agent left or disconnected before your reconnection (they won’t magically rejoin). • The agent was removed server-side (session expired, removed via API, or room closed) while you were offline. • The agent process crashed or was terminated during the network outage. • A duplicate-identity conflict occurred and another participant took the agent identity, disconnecting the original agent. • Minor propagation delays: the participant list may take a short moment to fully sync after reconnection. What to do in your app: • After

RECONNECTED

, check the

remoteParticipants

(or participant list) to confirm the agent is present. • If the agent is missing, handle it (show UI, retry connecting the agent, or trigger your agent-side recovery). • Use

PARTICIPANT_CONNECTED

/

PARTICIPANT_DISCONNECTED

events to track arrivals/leaves for more robust logic. Would you like a short snippet that checks for a specific agent identity after

RECONNECTED

and handles both present/missing cases? Sources: Connecting to LiveKit | LiveKit docs | Job lifecycle | LiveKit docs | Rooms, participants, and tracks | LiveKit docs

usually, on agent disconnection is better to disconnect from the room and reconnect to a new one or add a timeout and wait to see if participant reconnects in time?

Good question — both approaches are valid; the best choice depends on your UX, resource constraints, and how quickly an agent can realistically recover. Here’s a concise guide to choose and implement a robust pattern. Recommendation (default): use a short configurable timeout and wait for the agent to reconnect, then fall back to creating/joining a new room if they don’t. This balances user experience (less disruption) with resilience. Why prefer a timeout-first approach • Better UX: preserves the existing session, chat history, and any negotiated state if the agent briefly drops and returns. • Avoids churn: keeps participant IDs, track permissions, and server-side state intact. • Flexible: you can tune timeout length to your environment (mobile networks vs. stable LAN). When to immediately move to a new room • Long-running agent recovery is unlikely (agent process crashed or was intentionally terminated). • You must free resources quickly (server limits or billing concerns). • Your workflow requires a fresh session (different routing, new agent assignment) without waiting. Practical pattern (timeout + fallback) 1. On client

RECONNECTING

, start a timeout (e.g., 15–60s, configurable). 2. If

PARTICIPANT_CONNECTED

for the agent (or you detect their tracks) during the timeout, cancel fallback and continue. 3. If the timeout elapses with agent absent, call

room.disconnect()

and either: ◦ create/join a new room and re-establish state, or ◦ trigger agent reassignment logic. 1. Emit telemetry/logs for visibility (how often agent reconnections succeed vs. fallbacks). Tiny snippet (conceptual)

# on RECONNECTING:
start_timeout(30, on_timeout)

# on PARTICIPANT_CONNECTED(agent_id):
cancel_timeout()

# on_timeout:
await room.disconnect()
# then create/join new room or trigger fallback flow

Tuning tips • Short timeouts (5–10s) suit fast reconnections; longer (30–60s) suit flaky networks. • Consider exponential backoff if you attempt multiple reconnect cycles. • Use external signals (agent heartbeats, process health) to decide faster when agent is definitely gone. Would you like a ready-to-run snippet that ties into LiveKit events (

RECONNECTING

,

PARTICIPANT_CONNECTED

,

PARTICIPANT_DISCONNECTED

) for your exact timeout value and fallback behavior?