Data channel fails with "PC manager is closed" while audio/video work fine (publishData)

Client SDKs
,
1

Hi team, we’re on the Build (free) plan and hit what looks like a real bug, already filed via the “Report Service Outage” form two days ago with no response yet – posting here too since this is actively blocking our product’s live-session features for real users.

Symptom: room.localParticipant.publishData() throws UnexpectedConnectionState: PC manager is closed (from ensureDataTransportConnected → ensurePublisherConnected) – but audio/video publish and playback work fine in the exact same session, at the exact same time. It looks like the data-channel-specific negotiation path is failing while the media path succeeds.

What we ruled out before posting:

  • Not network quality – reproduced identically on strong WiFi (zero disconnects/timeouts recorded server-side) and on mobile data.
  • Not application code – happens identically on an older, previously-working feature and on brand-new code using the same publishData API.
  • Not permissions/tokens – both host and guest tokens grant identical canPublish/canSubscribe/canPublishData: true, confirmed via the actual JWT grants in the session event payloads.

Project: p_4h2vfxklklg (“Progmetics OS”). livekit-client ^2.22.0, @livekit/components-react ^2.9.24, livekit-server-sdk ^2.18.0. Affected sessions include RM_o2xJyUgcFSqN, RM_6rQfc8nKbNLv, RM_ytWMiudkXamb, and RM_ATviyYitbdAY – all show the same “PC manager is closed” error on the data channel only. One detail that may or may not be related: host and guest were routed to different regional edges (odubai1a vs ohyderabad1a) in some of these sessions – flagging in case it’s relevant, though we don’t believe cross-region routing itself is the bug. Happy to share full console traces, session event payloads, or a screen recording of a reproduction if that helps – just let us know what’s most useful.

2

I do see participants leaving and joining for some of those sessions, e.g. https://cloud.livekit.io/projects/p_/sessions/RM_6rQfc8nKbNLv/events. As a first step, it might be worth checking that room.state is not disconnected prior to publishing. Also log room.localParticipant.sid prior to publishing, to check that this has not changed.

3

Thanks for looking into this, Darryn.

Those leave and join events in that session are expected. That was one of our own live test sessions with a real guest joining over the network, so reconnects from normal network handoffs are part of the test itself, not a symptom on their own. We have also reproduced the same publishData failure on sessions with zero recorded disconnects server side, so I don’t think reconnect churn is the root cause by itself, though it’s a fair thing to rule in or out.

We just added the diagnostics you suggested. room.state and room.localParticipant.sid are now logged immediately before every publishData call across our poll, chat, and reaction components. Next time this happens in a real session we will have that data and can share the console output, plus the exact session id, so it can be correlated against the server side event log.

Will follow up here once we catch it again.

4

I’d agree with that - I remember one of your example rooms you gave (I think it was RM_ATviyYitbdAY didn’t have disconnects) so there’s possibly something more nuanced going on.

Sounds like a plan :+1: