Double execution of event listeners after remounting OTSession

[evillemez]

Bug Report

Current behavior

If OTSession is remounted, event listeners it receives from the parent component will be called twice for a time. I believe this is related to #262, but am not 100% sure.

Steps to reproduce

• Create a component that wraps OTSession and defines event listeners for connectionCreated, streamCreated, connectionDestroyed and streamDestroyed.
• This parent component should be configured to mount OTSession only in the case where the NetInfo.isConnected status is true.
• Join a call
• On one side (we'll call this the local user), force a network error by disabling wifi, which will result in unmounting OTSession
• On the local side the disconnect will be seen immediately
• On the remote side, the disconnect will not be seen until 1 min has passed (this is the time limit Opentok is enforcing before considering a connection dead and cleaning it up)
• Before the minute has elapsed (say after 20s), re-enable the wifi on the local side
• OTSession will remount and the two sides will be reconnected
• At the 1min mark after wifi was originally disabled, on the local side, you will see the connectionDestroyed, streamDestroyed events fire from the original connection. On the remote side you will see a streamDestroyed and connectionDestroyed event from the old connection as well.

What is the current bug behavior?

Registered event handlers are firing from an instance of OTSession which was previously unmounted.

What is the expected correct behavior?

Event handlers from old instances should be fully cleared, only triggered for the most recently mounted instance.

Other thoughts

I think part of the issue here may be shared state at the native level. If one wanted to have multiple sessions going (see #218) it is currently not possible, but another side effect of the shared state is that even in the case of only having one instance at a time in the RN layer, if a user has had to disconnect and reconnect, it is resulting in conflicting from the previously destroyed instance.

The effect of this at the app level is that it's making it impossible to tell to the difference between real disconnect events, and phantom disconnect events from a previous instance. So we have cases where two users get reconnected, but our app thinks they are disconnected because of the previous connection/streams timing out.

I've added extra checks to verify the specific stream and connection IDs, but it's not enough, because on the local side it will still see a streamDestroyed and connectionDestroyed event for the stream/connection that is actually still connected in the new instance, because the remote side still has the same stream/connection as it did before the disconnect on the local side.

[msach22]

@evillemez Thanks for filing this. The way I'm reading this, I'm thinking that the events are triggering in the second instance because the first local user has officially disconnected. To verify this, could you please mount the second instance of OTSession without any event handlers and see if the first ones are fired?

[evillemez]

That's what I think is happening too. I'll try that test as soon as I can, it may be a little tricky to set up.

[msach22]

Thanks @evillemez - please keep me updated

[niraj1997]

I am also facing the same issue.

Is there any update on it?

@msach22, is there any update on it?

[evillemez]

@msach22 I'm still sure this is an issue, not finding any other explanation for the extra disconnect signals.

Is there more information anyone of us, me, or @Aserga or @niraj1997 can provide here? It's a serious issue for us unfortunately, because we unmount/remount the session in the case of a party losing their network connection, or if the session/publisher/subscriber trigger an error.

[evillemez]

@msach22 @ggoldens I saw the PR referencing this - is this potentially fixed in 0.12.0?

[ggoldens]

Hi @evillemez sorry for the late reply. Yes, it should be fixed in 0.12.0. Could you please confirm if after upgrading it works as expected?
Thanks

[ggoldens]

This should be fixed in opentok-react-native >= 0.12.0. Closing this issue.

[julianoddreis]

@ggoldens Not fixed yet. I'm using 0.12.1 and still not clearing the event handlers.

[TomasUhrik]

I can confirm that 0.12.1 still has this issue.

To elaborate a bit: I think that all unmounted sessions still "live" somewhere as @evillemez nicely says it here:

Registered event handlers are firing from an instance of OTSession which was previously unmounted.

It's not limited to only one session though. Meaning that if you unmount 5 sessions and mount a new one, then any upcoming events get called 6 times.

[msach22]

@TomasUhrik Are you only seeing this on iOS or on Android as well?