[Bug] Infinite reconnection loop (negotiation disconnected) introduced in @livekit/protocol@1.45.8
Describe
When using the LiveKit React/JS SDK, the client enters an infinite reconnection loop (connected -> reconnecting -> connected -> reconnecting...) when establishing a connection to the room.
The signaling connects successfully, but fails immediately after attempting to publish tracks with a negotiation disconnected warning.
I have isolated the issue to the recent release of @livekit/protocol@1.45.8. Downgrading to @livekit/protocol@1.45.7 completely resolves the issue, and the connection remains stable.
To Reproduce
Steps to reproduce the behavior:
- Initialize a LiveKit room connection in a React application using the latest SDKs and
@livekit/protocol@1.45.8.
- Attempt to connect and publish a local track.
- Observe the
ConnectionState in the console.
- The state will endlessly loop between
connected and reconnecting.
Expected behavior
The client should connect to the room, successfully negotiate the WebRTC connection, publish tracks, and remain in a stable connected state, as it does in version 1.45.7.
Logs
Here is a snippet of the console sequence when the bug occurs:
signal connected {room: undefined, ...}
connected to LiveKit Server edition: 0, version: 1.9.0, protocol: 16...
connection state changed: connecting -> connected
publishing track ...
⚠️ negotiation disconnected
reconnecting, attempt: 0
connection state changed: connected -> reconnecting
signal connected {room: ...}
...
⚠️ failed to remove track
Failed to execute 'removeTrack' on 'RTCPeerConnection': The sender was not created by this peer connection.
(Note: An initial warning also fires: Initial connection failed: v1 RTC path not found. Consider upgrading your LiveKit server version -- Retrying)
Environment Details:
- LiveKit Server Version: 1.9.0
- Client SDK Version:
livekit-client v2.19.0 (via sdk=js&version=2.19.0 in signal URL)
- LiveKit Protocol Version: 1.45.8 (Buggy) / 1.45.7 (Working)
- Browser: Chrome 147
- OS: macOS (Mac OS X 10.15.7)
Workaround
Explicitly pinning or downgrading the protocol package in package.json:
"resolutions": {
"@livekit/protocol": "1.45.7"
}
(Or equivalent using npm overrides/yarn resolutions).
Additional context
Because the signaling succeeds but the WebRTC peer connection drops at negotiation disconnected, it seems something in the 1.45.8 protocol update is causing a failure in how the client and server agree on the media tracks or SDP, particularly when interacting with an older Server version (v1.9.0).

[Bug] Infinite reconnection loop (negotiation disconnected) introduced in
@livekit/protocol@1.45.8Describe
When using the LiveKit React/JS SDK, the client enters an infinite reconnection loop (
connected -> reconnecting -> connected -> reconnecting...) when establishing a connection to the room.The signaling connects successfully, but fails immediately after attempting to publish tracks with a
negotiation disconnectedwarning.I have isolated the issue to the recent release of
@livekit/protocol@1.45.8. Downgrading to@livekit/protocol@1.45.7completely resolves the issue, and the connection remains stable.To Reproduce
Steps to reproduce the behavior:
@livekit/protocol@1.45.8.ConnectionStatein the console.connectedandreconnecting.Expected behavior
The client should connect to the room, successfully negotiate the WebRTC connection, publish tracks, and remain in a stable
connectedstate, as it does in version1.45.7.Logs
Here is a snippet of the console sequence when the bug occurs:
(Note: An initial warning also fires:
Initial connection failed: v1 RTC path not found. Consider upgrading your LiveKit server version -- Retrying)Environment Details:
livekit-clientv2.19.0 (viasdk=js&version=2.19.0in signal URL)Workaround
Explicitly pinning or downgrading the protocol package in
package.json:(Or equivalent using npm overrides/yarn resolutions).
Additional context
Because the signaling succeeds but the WebRTC peer connection drops at
negotiation disconnected, it seems something in the1.45.8protocol update is causing a failure in how the client and server agree on the media tracks or SDP, particularly when interacting with an older Server version (v1.9.0).