Reconnection stays in failover followup

Video SDK
1

Video SDK web v2.2.0

Hi @vic.yang

I wanted to follow up on my previous post titled: On connection change fail repeated for just one user. We extended the jwt token lifespan to two hours so it will never expire mid session. Now, the reconnect does not fail, however, it seems like the automatic reconnect in the on connection change still has some problems.

With session id 8/6FzQjyRSqjgnj/XEVjtg== , the on connection change state went from Reconnection due to failover to Connected, but the user’s isInFailover prop reportedly stayed true (happens around the 22nd minute mark of the session). I would appreciate it if you could take a look at what might be happening.

Thank you again for your help

2

Hi David,

I resolved this issue by relying only on native browser events (online and offline) and handling reconnection logic manually. I only listen for the Connected state in the connection-change event and use a retry mechanism for join() with a limit of 2 attempts. I avoid calling init() again and fully destroy and recreate the client instance on reconnection.

connection-change handling

client.on('connection-change', async ({ state }) => {
  if (state === 'Connected') {
    isConnected = true;
    retryCount = 0;
    await syncSessionState();
  }
});

offline and online listeners

window.addEventListener('offline', () => {
  isConnected = false;
});

window.addEventListener('online', async () => {
  try {
    await destroyClient();
  } catch (e) {}

  client = ZoomVideo.createClient();
  attachEvents(client);
  await joinWithRetry(token, userName);
});

destroyClient function

async function destroyClient() {
  try {
    if (client) {
      await client.leave();
      await client.destroy();
    }
  } catch (e) {}
}

joinWithRetry function

async function joinWithRetry(token, userName) {
  while (retryCount < MAX_RETRIES) {
    try {
      await client.join(token, userName);
      return true;
    } catch (err) {
      retryCount++;
      await new Promise(res => setTimeout(res, 1000));
    }
  }
  return false;
}

syncSessionState function

async function syncSessionState() {
  try {
    const users = client.getAllUser();
    users.forEach(u => {
      console.log(u.userId, u.audioStatus, u.videoStatus);
    });

    if (channelClient && !channelClient.isConnected()) {
      await channelClient.connect();
    }

    const rec = await client.getRecordingInfo();
    console.log(rec);
  } catch (e) {}
}

This approach avoids internal SDK failover issues and ensures the session state is consistently maintained. Let me know if you want this structured as a reusable module.

— Naeem Ahmed

3

Hi @David30

8/6FzQjyRSqjgnj/XEVjtg==

After analyzing the logs, there were many users in the meeting. Based on the timestamp you provided, 22 minutes after the session started, User 16804864 disconnected from the server about 30 seconds after rejoining — possibly by directly closing the browser. Around 20 seconds later, a new user joined the session, likely representing the same person rejoining under a new user ID.

As a result, User 16804864 remained in the isInFailover state until the server’s heartbeat timeout mechanism removed them from the session.

Thanks
Vic

1 Like
4

This topic was automatically closed 25 hours after the last reply. New replies are no longer allowed.