We’ve recently been facing issues with strange disconnect behaviors.
For some reason, some disconnects cause that a publisher isn’t cleaned from the session. We’ve got multiple reports of publishers who got disconnected, re-joined again and were shown twice in the participant’s list after that.
This sounds like a client issue, but it must be something in the server. As soon as everybody leaves the session, it will stay there until the server gets restarted. The session list we receive from the OpenVidu API then still contains this session and shows that a publisher would still be in there.
Are there any such known issues with disconnects yet? Unfortunately, we didn’t find a way to replicate this issue on purpose, but I’ve heard from some customers that it’s an issue with disconnecting while sharing your screen which means that two publishers are active for a single participant.
We tried updating from v2.23.0 to v2.25.0 but the issue still persisted. We didn’t test v2.26.0 yet but couldn’t find a hint in the release notes regarding this issue.
Thank you in advance!
Is there a way to replicate such behavior? I mean, is there something we can do to replicate your issue in our side? Does it happen randomly?
Hi @cruizba ,
I think I finally found a way to replicate the issue.
First of all, our application is public and can be accessed through the internet from anywhere.
This is what I did to replicate the issue:
- Connect to the internet
- Connect to the VPN of my company
- Create a new session and join as publisher (in my case, with audio and video)
- Disconnect from the VPN but keep the internet connection
This reliably leads to a “ghost publisher” that isn’t cleaned from the OpenVidu backend.
The issue does not seem to be the disconnect itself because the same thing doesn’t happen if I completely disconnect from the internet (I’ve tested this multiple times). Instead, the issue seems to be that OpenVidu tries to reconnect to the session through the internet without using the VPN connection after the VPN was disconnected.
The javascript console outputs the following:
I can also replicate the issue without using a VPN by just switching internet connection (e.g. switching from WiFi to LAN or vice versa).
I hope this helps resolving the issue!
I am not able to replicate the issue just by switching from WiFi to mobile network. In all iterations I’ve performed this test, the connection recovers fine, with this log in the client-side:
@pabloFuente This is weird - I just tried again today and the issue persists and can be replicated reliably. I also tried disabling forceMediaReconnectionAfterNetworkDrop but that doesn’t change anything.
I just tried replicating using openvidu-getaroom and the reconnect works fine - must be an issue with our custom app. Do you have any idea or hint what could cause this?
Have you tried replicating the issue using for example this app deployment? openvidu-getaroom
I mean, performing the network switch or VPN disconnection you mentioned in a previous message, but against that demo application.
Yes, I did and it worked. So I had a further look at our code base and compared disconnection handling. It seems like I found the issue:
session.on('reconnecting', () => {
session.disconnect();
});
We did this initially because we had other issues with reconnection - but I see why this doesn’t make much sense. Anyway, my issue is solved by removing this code snippet.
