fix(desktop): retry host SFU connect instead of failing on first ICE miss#24
Merged
Conversation
…miss
On a flaky multi-homed host the publisher's first ICE negotiation often
fails ("could not establish pc connection") even though a retry immediately
lands on a working candidate pair — the SFU logs show exactly this (first
attempt dropped, second "participant active" via udp relay). Previously that
first failure went straight to the catch and surfaced a fatal error toast,
even though reconnecting would have worked.
startHosting now retries room.connect() up to 3x with backoff, disconnecting
between attempts (those intentional drops are suppressed so they don't flash
the "Disconnected" toast). The mic publish is also made non-fatal — a
transient publisher-PC hiccup no longer aborts hosting. Only a genuine
exhaustion of all retries surfaces the error.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
vu1nz Security Review0 finding(s) in PR #? No security issues found. |
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
1 participant
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.
Problem
Users on a flaky/multi-homed host kept seeing "Streaming error: could not establish pc connection" even on 0.8.2. The SFU logs show the publisher's first ICE negotiation fails, but the very next attempt connects fine via the TURN relay (
participant active,udp relay). PR #21 suppressed the toast for livekit's own post-connection reconnects, but the initialroom.connect()/ mic publish still went straight to the catch and surfaced a fatal toast on that first miss.Fix
startHostingnow retriesroom.connect()up to 3× with backoff, disconnecting between attempts. Those intentional disconnects are suppressed (aconnectingguard) so they don't flash the "Disconnected" toast. The mic publish is also made non-fatal — a transient publisher-PC hiccup no longer aborts hosting (the screen share publishes separately and livekit recovers). Only genuine exhaustion of all retries surfaces an error.This is the "can't you just retry?" fix: it turns the common first-attempt-fails / second-attempt-works case into a silent success.
Test
Added two cases (fake timers): connects on a later attempt with no error toast (
isHostingtrue, error null, 2 connect calls, 1 disconnect); and surfaces the error only after all 3 attempts fail. Existing 3 pass. 5/5; full monorepo lint passes.🤖 Generated with Claude Code