fix(desktop): guard startHosting re-entry so screen share survives reconnect#25
Merged
Conversation
…connect The 0.8.3 connect-retry collided with the auto-start-hosting effect, which re-fires startHosting whenever isHosting is false — which it stays through the retries. With no re-entrancy guard, overlapping startHosting calls each built their own Room and connect/disconnected on top of each other (a DUPLICATE_IDENTITY / CLIENT_REQUEST_LEAVE storm in the SFU logs). The screen share got published on a connection that was then torn down, so the host saw camera + black presentation. - startHosting now bails if a start is already in-flight or a room exists. - On failure it tears down roomRef so the next (sequential) attempt is clean. - A terminal Disconnected releases roomRef so re-hosting still works. Tests: concurrent start builds one connection; re-host works after a terminal disconnect; existing retry/reconnect cases still pass (7/7). 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 (regression from 0.8.3)
After the connect retried, the host saw camera + black presentation — the screen share didn't survive. SFU logs showed a connection storm: the same identity publishing SCREEN_SHARE on multiple participant IDs with a flurry of
DUPLICATE_IDENTITY/CLIENT_REQUEST_LEAVE.Cause: the auto-start-hosting effect re-fires
startHostingwheneverisHostingis false — which it stays through the 0.8.3 connect retries. With no re-entrancy guard, overlappingstartHostingcalls each built their ownRoomand connect/disconnected on top of each other. The screen share got published on a connection that was then torn down → black.Fix
startHostingbails if a start is already in-flight (startingRef) or a room already exists (roomRef).roomRefso the next attempt is clean and sequential.DisconnectedreleasesroomRefso re-hosting still works after a real drop.Net: one connection at a time, so the screen share publishes once on the stable connection and stays up — the retry/reconnect no longer disturbs the session.
Tests (7/7)
Added: concurrent
startHostingbuilds only one connection; re-host works after a terminal disconnect. Existing retry/reconnect cases unchanged. Full monorepo lint passes.🤖 Generated with Claude Code