Race condition may cause JitsiConference.prototype._doReplaceTrack to hang forever

[athouary]

Description

I consume lib-jitsi-meet in a custom user interface to connect and use a self-hosted docker-jitsi-meet. I've encountered some cases where the promise returned byJitsiConference.addTrack is pending forever, and after long researches, I've finally understood why.

The JitsiConference.prototype._doReplaceTrack promise resolves once the replaceTrack on all the existing Jingle Session (P2P and/or JVB) resolve. JingleSessionPC relies on AsyncQueue and pushes the replaceTrack call into it. In some rare case, when a 3rd user joins the conference and it goes from P2P to JVB, then the P2P JingleSession closes and the AsyncQueue is killed. This results in the replaceTrack to be pending forever.

Current behavior

A call to JitsiConference.addTrack or JitsiConference.replaceTrack may hang forever if the conference goes from P2P to JVB in the mean time.

Expected Behavior

The promises returned by those functions should either be resolved or rejected. Actually, it should most probably resolve and ignore the P2P session since it's not relevant anymore.

Possible Solution

We should probably call the all the pending task callbacks when killing an AsyncQueue, with a specific error that replaceTrack would catch. It would then resolve its promise (it seems ok not to manage to replace a track on a non-existing peer connection).

A more simple but dirtier solution would be to reject the promise after a timeout.

Steps to reproduce

1. Client A joins a Jitsi conference
2. Client B joins a Jitsi conference
3. Client A adds local tracks to the conference
4. Client B adds local tracks to the conference
5. Client C joins the conference before the tracks are completely added for one or both other users

Environment details

Reproduced on (non-exhaustive):

• lib-jitsi-meet v1699.0.0+683dc0fb
• docker-jitsi-meet stable-8960
• Clients on Chrome 117

[saghul]

We should probably call the all the pending task callbacks when killing an AsyncQueue, with a specific error that replaceTrack would catch. It would then resolve its promise (it seems ok not to manage to replace a track on a non-existing peer connection).

This sounds about right!