Fix: Publisher re-enable tracks after room connected in case of timeout#3674
Fix: Publisher re-enable tracks after room connected in case of timeout#3674BillCarsonFr wants to merge 1 commit intolivekitfrom
Conversation
|
Do we think this is an actual issue? Or is it more likely that the transport setup sometimes was racing and we ended up with a transport switch -> local connection switch which then ends up in a locked or not cleaned up old transport -> unable to unmute |
Yes it is, as shown by the test. But it is not a final/big issue given that you can recover by muting/unmuting when it happens. Probably not occuring often but found 5 occurences in RS |
This definitely implies its another thing. (the publisher bug would make exactly that impossible!!) |
| // If it is PublisherTrackError (408), i.e the publishing timed out, | ||
| // because it took too long to connet to the room, we are safe because | ||
| // we registered to the RoomEvent.Connected to create the tracks once connected. | ||
| this.logger.error("Failed to enable tracks", e); |
There was a problem hiding this comment.
Do we want to inform the console log about that as well:
because it took too long to connet to the room, we are safe
and (very minor) connet -> connect`
In this case it is unresponsive for at least 15s. But it is not final like with the local transport hot swap |
|
Let s do this:
and merge? |
|
Should we merge this now, that we have the rc branch created? |
| ParticipantEvent.LocalTrackPublished, | ||
| this.onLocalTrackPublished.bind(this), | ||
| ); | ||
|
|
||
| this.connection.livekitRoom.once(LivekitRoomEvent.Connected, () => { |
There was a problem hiding this comment.
I'm noticing some leaks: both the LocalTrackPublished callback and the Connected callback should not remain set after the scope ends
3 participants
Fixes https://github.com/element-hq/voip-internal/issues/442
We were calling
LocalParticipant#set(Microphone|Camera)Enabledexpecting it to be very resistent to early calls.It has support for waiting for the room to be connected in order to publish the track, but it is not unlimited, it will timeout
https://github.com/livekit/client-sdk-js/blob/1744ee4ec7aaed4e71c510c34fd21667364fcce6/src/room/participant/LocalParticipant.ts#L896
We want to support this case a little bit better by ensuring the expected tracks are published once the room is really connected (signal connected).
This is not yet a good "connecting" experience. Because until you are connected to livekit, your video loop back will be lacking, and unmuting would be unresponsive.