fix(prosody-auth): Don't loose initial tracks.

[hristoterezov]

During the prosody login cycle the initial GUM tracks were lost causing the user to start the call without local media and audio/video mute buttons staying forever in pending state.

[saghul]

It doesn't need to be. It doesn't even need access to the store so it doesn't even need to be async.

export function initPrejoin(tracks: Object[], errors: Object) {
    return async function(dispatch: IStore['dispatch']) {
        dispatch(setPrejoinDeviceErrors(errors));
        dispatch(prejoinInitialized());

        tracks.forEach(track => dispatch(trackAdded(track)));
    };
}

You could rewrite this to take the store as a parameter and just call it, since it's not really an action. Then in there you can batch-dispatch the actual actions.

[saghul]

This feeels like the wrong place to be handling this. Authentication should not be handling track stuff.

You can handle this in the media middleware, since the recoverable flag will already be set once you calll next when handling this action.

[hristoterezov]

But then how fo we guarantee that the media middleware will be executed after the authentication one? Aren't they executed in the order of the imports. This doesn't sound like very intuitive solution.

Moreover the whole story is a little bit more complicated. We need to keep the gum promise only for the login dialog and in all other cases we don't need it... IMHO the whole thing doesn't look so bad to be here.

[saghul]

Ditto.

[saghul]

When will the connection begin again?

[saghul]

I see some of the logic got moved to base/conference, but only to the web middleware. When does mobile start connecting again?

[hristoterezov]

we decided with @damencho to remove the reconnect in order not to flood the infrastructure with reconnects. IIRC the UX now will be that the user will see an error and can reload or press the Join button again.

[saghul]

Generally speaking, base/media has always represented user intent, that is, a muted a flag in here does not necesssarily mean there is a track.

The initial gUM promise is concerned with actual tracks, which fits better in base/tracks.

[hristoterezov]

Make sense!

Now the problem is that base/tracks is just an array currently. This will include converting it into some kind of object to keep the tracks and also the promise. And this could potentially lead to a lot of changes.

Do you insist on doing the change as part of this PR or you prefer a follow up PR with the change?

[saghul]

I'd like to see some more details on the commit description too, since I suspect the problem of remaining stuck in a broken state wasn't reproducing all the time, right?

[hristoterezov]

I'd like to see some more details on the commit description too, since I suspect the problem of remaining stuck in a broken state wasn't reproducing all the time, right?

yes. it happens when the prejoin is not enabled.

[saghul]

🚀