Ensure connection state mismatches aren't triggered for ongoing PC connection attempts

[lukasIO]

we use STATE_MISMATCH today (additionally, unfortunately) for cases where the expected current connection state doesn’t reflect the connection state of the underlying engine (and thus from the webrtc peer connections). This can happen if the first publication of a track takes too long. In this time the expected connection state is connected but the peer connection transitions to connecting while establishing the connection.

This PR adds the connecting state to the possible values to verify the transport is working as expected to ensure only actual failures and mismatches and not intermediate states are used to trigger a connection state mismatch.

Summary by CodeRabbit

• Bug Fixes
  • Resolved an issue where connection state mismatches could be incorrectly triggered while peer connection attempts were still in progress, improving connection reliability and stability.

[changeset-bot]

🦋 Changeset detected

Latest commit: 8b8b266

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
livekit-client	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[coderabbitai]

📝 Walkthrough

Walkthrough

The changes update the connection verification logic to recognize both CONNECTING and CONNECTED states as valid transport states, rather than only CONNECTED. A corresponding diagnostic log field is renamed to reflect this broader acceptance. A changeset entry documents the patch release.

Changes

Cohort / File(s)	Summary
Release Documentation .changeset/clever-guests-compare.md	Adds patch version changelog entry documenting connection state mismatch prevention for ongoing PC connection attempts.
Connection State Verification src/room/RTCEngine.ts, src/room/Room.ts	Updates verifyTransport() to accept both CONNECTING and CONNECTED states via allowedConnectionStates array; renames diagnostic log field from transportsConnected to transportsConnectedOrConnecting to reflect this change.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 When connections seek their dancing way,
Through CONNECTING states throughout the day,
No mismatch now shall lead astray,
The rabbit hops—hooray, hooray! 🎉

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The pull request title accurately and specifically summarizes the main change: preventing false connection state mismatches during ongoing PeerConnection establishment by accepting the CONNECTING state.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch lukas/harden-state-mismatch

---

📜 Recent review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 014346e and 8b8b266.

📒 Files selected for processing (3)

• .changeset/clever-guests-compare.md
• src/room/RTCEngine.ts
• src/room/Room.ts

🧰 Additional context used

🧠 Learnings (2)

📓 Common learnings

Learnt from: 1egoman
Repo: livekit/client-sdk-js PR: 1798
File: src/room/data-track/utils.ts:118-121
Timestamp: 2026-02-03T17:59:43.931Z
Learning: In the client-sdk-js codebase at `src/room/data-track/utils.ts`, the `isBefore()` method in `DataTrackTimestamp` is now wraparound-aware and correctly delegates to `WrapAroundUnsignedInt.isBefore()` to handle sequence number wraparound in comparisons. This behavior was updated following shijing's comment.

📚 Learning: 2026-02-03T17:59:43.931Z

Learnt from: 1egoman
Repo: livekit/client-sdk-js PR: 1798
File: src/room/data-track/utils.ts:118-121
Timestamp: 2026-02-03T17:59:43.931Z
Learning: In the client-sdk-js codebase at `src/room/data-track/utils.ts`, the `isBefore()` method in `DataTrackTimestamp` is now wraparound-aware and correctly delegates to `WrapAroundUnsignedInt.isBefore()` to handle sequence number wraparound in comparisons. This behavior was updated following shijing's comment.

Applied to files:

• src/room/RTCEngine.ts
• src/room/Room.ts

🔇 Additional comments (3)

.changeset/clever-guests-compare.md (1)

1-5: LGTM!

Changeset entry is well-formed and accurately describes the patch.

src/room/Room.ts (1)

2304-2313: LGTM!

The diagnostic log field rename to transportsConnectedOrConnecting accurately reflects the updated semantics of verifyTransport().

src/room/RTCEngine.ts (1)

1476-1493: Good change — widens transport verification to accept ongoing connections.

The logic correctly allows CONNECTING alongside CONNECTED as valid states during transport verification. This prevents false STATE_MISMATCH disconnects when the PeerConnection is legitimately negotiating (e.g., during initial track publication).

The safety net is adequate: WebRTC PCs that fail to connect transition to failed (→ PCTransportState.FAILED), which is still caught by this check. The initial connection path also has an explicit peerConnectionTimeout via waitForPCInitialConnection.

_{✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

size-limit report 📦

Path	Size
dist/livekit-client.esm.mjs	86.52 KB (-0.01% 🔽)
dist/livekit-client.umd.js	96.8 KB (-0.02% 🔽)

[1egoman]

Makes sense at a high level to me, though I haven't really had to dive too deeply into the RTCEngine yet so getting a 👍 from somebody more familiar could be a good idea.