ERROR "publisher data channel closed unexpectedly" on room delete shortly after session start (1.6.4)

[miguelmoralai]

When a session is shut down and the room is deleted shortly after it is initialized (via delete_room_on_close=True), three ERROR-level logs are emitted during teardown:

ERROR livekit::rtc_engine::rtc_session:646:livekit::rtc_engine::rtc_session - publisher data channel '_reliable' closed unexpectedly
ERROR livekit::rtc_engine::rtc_session:646:livekit::rtc_engine::rtc_session - publisher data channel '_lossy' closed unexpectedly
ERROR livekit::rtc_engine::rtc_session:646:livekit::rtc_engine::rtc_session - publisher data channel '_data_track' closed unexpectedly

They appear right after the framework deletes the room:

INFO  deleting room on agent session close (disable via RoomInputOptions.delete_room_on_close=False)
ERROR ... publisher data channel '_reliable' closed unexpectedly
ERROR ... publisher data channel '_lossy' closed unexpectedly
ERROR ... publisher data channel '_data_track' closed unexpectedly

The call itself completes cleanly (shutdown callbacks run, post-call work succeeds). The data channels are closed because the room was deleted on purpose, so logging this at ERROR looks like a false positive during normal teardown.

Why it seems to happen

This appears to be a timing race during teardown: when ctx.shutdown() runs very early in the call, the room is deleted (server-side close of the data channels) before the session's local closed flag is set, so the new check at rtc_session.rs:646 (added in livekit/rust-sdks#1137) sees the channel close as unexpected. It is most reproducible when the session is shut down just a few seconds after the room is created.

Steps to reproduce

1. Start an agent session.
2. A few seconds after the room is initialized, call ctx.shutdown() with delete_room_on_close=True (default).
3. Observe the three ERROR logs above during teardown.

Expected

A room deleted intentionally on session close should not log publisher data channel ... closed unexpectedly at ERROR level (e.g. suppress/downgrade when the close was initiated by us).

Versions

• livekit-agents 1.6.4
• livekit (rtc) 1.1.12

[longcw]

are you using self-hosted livekit server?

[miguelmoralai]

are you using self-hosted livekit server?

No

[dbl8005]

Ran this down today — the rust-side fix for this is merged but not reachable from any published Python wheel, which is probably why people are still hitting it.

Chain, for anyone finding this:

• The log comes from rtc_session.rs, fired from the data-channel on_state_change callback. It fires only when !closed && !disconnecting && publisher_pc.is_connected().
• delete_room_on_close (default True) is fired from RoomIO._on_agent_session_close as a background task while the room is still connected, and the room is only disconnected later at job shutdown (ipc/job_proc_lazy_main.py). So the server closes the publisher data channels from the remote side before the engine sets its flags, and an expected close is logged as a fault.
• Fixed in rust-sdks by livekit/rust-sdks@e283d9fd (2026-07-17) — "don't log expected publisher data channel close as unexpected".

Why it hasn't reached anyone: the newest livekit rtc wheel on PyPI is 1.1.13, published 2026-06-30 — before the fix. And livekit/python-sdks pins rust-sdks as a git submodule, currently at dad794d4 (2026-06-30), which is 32 commits behind e283d9fd. So a wheel built from python-sdks main today still wouldn't contain it. It needs a submodule bump and a release.

Handy tell for which side you're on: the pre-fix source logs at line 646, the fixed source at line 660.

Minimal reproduction (real LiveKit, livekit==1.1.13, no agents needed):

1. Create a room, connect, publish an audio track and pump frames.
2. Call DeleteRoom while still connected → the three ERRORs (_reliable, _lossy, _data_track).
3. Same thing but await room.disconnect() before DeleteRoom → silent.

The published audio track matters: publishing only data leaves the publisher PC down, the guard never fires, and you get a false negative. That cost me a round trip.

Workaround that doesn't involve suppressing the log (worth noting, since the same diagnostic is what catches an oversized data message silently killing a channel — livekit/rust-sdks#1137): set RoomInputOptions.delete_room_on_close=False and delete the room yourself from ctx.add_shutdown_callback(...), which runs after await room.disconnect(). Rooms still get deleted, nothing races, and the ERROR goes back to meaning something. Room.disconnect() early-returns when already disconnected, so the SDK's own disconnect stays a no-op.

[IngLP]

Update from a self-hosted production deployment: the fix is now shipped in a published wheel (livekit 1.1.14) and this still reproduces — through a different trigger than delete_room_on_close.

Versions

• livekit (rtc) 1.1.14 — the rtc-v1.1.14 tag pins rust-sdks submodule 63128d01 (2026-07-29), which is 18 commits ahead of livekit/rust-sdks@e283d9fd and 0 behind, so the guard from fix: don't log expected publisher data channel close as unexpected rust-sdks#1224 is in.
• livekit-agents 1.6.8
• self-hosted livekit-server v1.13.5

The line number confirms which side we're on — the post-fix source logs at 679 (pre-fix it was 647):

ERROR livekit::rtc_engine::rtc_session:679:... - publisher data channel '_reliable' closed unexpectedly
ERROR livekit::rtc_engine::rtc_session:679:... - publisher data channel '_lossy' closed unexpectedly
ERROR livekit::rtc_engine::rtc_session:679:... - publisher data channel '_data_track' closed unexpectedly

Trigger: server-side idle-room close, not delete_room_on_close

Our agent runs a short post-call turn after the (SIP) caller hangs up, so it outlives the last non-agent participant and is still connected when the room's empty timeout expires:

11:31:47.001  livekit-server  removing participant        (caller hangup)
              ... agent still connected, finishing post-call work ...
11:32:07.124  livekit-server  closing room / closing idle room
11:32:07.130  agent           ERROR _reliable / _lossy / _data_track closed unexpectedly

~5 ms after the server starts closing the room.

Why the guard doesn't catch it

On this path the server does send Leave{Disconnect}, so the precondition for disconnecting = true is met:

Room.CloseIfEmpty → Room.Close(ParticipantCloseReasonRoomClosed) → p.Close(sendLeave=true, …, isExpectedToResume=false) → sendLeaveRequest(...) with Action = DISCONNECT (pkg/rtc/participant_signal.go).

But the flag is set on the signal path, while the trigger arrives on the transport path (the data-channel on_state_change callback), and nothing orders the two — the server writes the Leave on the signal WS and tears the transport down concurrently. When the transport teardown wins the race, !closed && !disconnecting && publisher_pc.is_connected() still holds and the ERROR fires.

That matches what we measure: over 7 days of production traffic, 4 occurrences (12 log lines) across 166 room closes (~2.4%) — always all three channels at once, always 3–9 ms after the server's closing room, never mid-call. So livekit/rust-sdks#1224 made this much rarer rather than eliminating it.

Possible directions

Maintainers will know better, but from the outside:

• also flag disconnecting when a remote transport teardown begins while a Leave may be in flight, or
• debounce the log — on DC close, re-check closed/disconnecting after a short delay before logging, or
• suppress once the signal connection is already closing.

Worth keeping the diagnostic itself: it's the same log that catches an oversized data message silently killing a channel (livekit/rust-sdks#1137). Happy to provide more logs if useful.