Repository navigation
Send reliable data after a full reconnect instead of dropping it - #1277
Open
hiroshihorie wants to merge 2 commits into
Open
hiroshihorie wants to merge 2 commits into
hiroshihorie wants to merge 2 commits into
Conversation
sendDataPacket parked a reliable packet sent during any reconnect for the resume replay. A full reconnect never runs that replay, so the packet was reported as sent and never went out. publishData, RPC and data stream writes all hit this. A reliable send now waits the reconnect out and goes out on the connection it leaves, the way rust-sdks waits for reconnection in publish_data. It fails with UnexpectedConnectionState if the engine closes instead. All waits happen before the sequence number is taken, a send that a full reconnect interrupts while it waits for the publisher goes round again instead of failing, and nothing awaits between the last reconnect check and the send. A full reconnect restarts the reliable sequence and clears the resend buffer, as client-sdk-js, client-sdk-swift and rust-sdks do for a new session. Lossy packets are still dropped during a reconnect rather than sent late.
hiroshihorie
marked this pull request as ready for review
November 3, 2026 07:19
hiroshihorie
requested review from
changt,
cloudwebrtc and
xianshijing-lk
as code owners
November 3, 2026 07:19
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
…ends-full-reconnect
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #1267, which is stacked on #1268. This PR is one commit.
A reliable data packet sent while the engine does a full reconnect was reported as sent and never went out.
sendDataPacketparked it for the resume replay, and a full reconnect never runs that replay.publishData, RPC and data stream writes all hit this. Found while checking Devin's finding on #1267.Change
UnexpectedConnectionStateif the engine closes instead, which is how a reconnect that gives up ends.Publisher connection reset. Nothing awaits between the last reconnect check and the send, so a reliable packet is no longer parked.Other SDKs
This follows rust-sdks, where
publish_dataholds the reconnect lock's read guard. client-sdk-js has the same loss Flutter had.Tests
test/core/reliable_send_reconnect_test.dart: a send during a full reconnect reaches the new channel only after the reconnect finishes, sequence numbers restart at 1, a waiting send fails when the engine closes, and a resume still sends once. The first three fail without this change.flutter analyze,dart analyze web/, format, import order and version check pass.livekit-server --dev. A sender publishes a numbered reliable packet every 20 ms and the server forces a full reconnect partway.Publisher connection resetThe reconnect group (full reconnect, disconnect during a full reconnect, migration, node failure) and both data channel scenarios also pass on an earlier revision of this branch.