mirror of
https://github.com/livekit/livekit.git
synced 2026-03-30 19:55:41 +00:00
65d8aa2847
There are two very very edge case scenarios this is triyng to address. Scenario 1: ----------- - both pA and pB migrating - pA migrates first and subscribes to pB via remote track of pB - while the above subscribe is happening, pB also migrates and closes the remote track - by the time the subscribe set up completes, it realises that the remote track is not open any more and removes itself as subscriber - but that removal is using the wrong `isExpectedToResume` as clearing all receivers has not run yet which is what caches the `isExpectedToResume`. - That meant, the down track transceiver is not cached and hence not re-used when re-subscribing via pB's local track - Fix it by caching the expected to resume when changing receiver state to `closing`. Scenario 2: ----------- - both pA and pB migrating - pA migrates first and subscribes to pB via remote track of pB - while the above subscribe is happening, pB also migrates and closes the remote track - pB's local track is published before the remote track can be fully closed and all the subscribers removed. That local track gets added to track manager. - While the remote track is cleaning, subscription manager triggers again to for pA to subscribe to pB's track. The track manager now resolves to the local track. - Local track subscription progresses. As the remote track clean up is not finished, the transceiver is not cached. So, the local track based subscription creates a new transceiver and that ends up causing duplicate tracks in the SDP offer. - Fix it by creating a FIFO in track manager and only resolve using the first one. So, in the above case, till the remote track is fully cleaned up, the track manager will resolve to that. Yes, the subscriptions itself will fail as the track is not in open state (i. e. it might be in `closing` state), but that is fine as subscription manager will eventually resolve to the local track and proper transceiver re-use can happen.