Duplicate participant appears when joining with slow network and OPERATION_CANCELLED / RECONNECTING_MEETING is returned

Video SDK
1

Video SDK Type and Version

Web Video SDK
Version: 2.2.12

Description

We are encountering an issue when a user joins a session under a slow or unstable network condition.

In some cases, the joining client receives the following error message:

JSON

{"type":"OPERATION_CANCELLED","reason":"RECONNECTING_MEETING","errorCode":3}

However, other participants in the session can already see that user as having joined. After the reconnect process completes, the same user appears again, resulting in two participant entries for the same user.

We would like to understand whether this is expected behavior, a known limitation, or a potential issue in the Web Video SDK reconnect flow.

Error?

JSON

{"type":"OPERATION_CANCELLED","reason":"RECONNECTING_MEETING","errorCode":3}

Troubleshooting Routes

  • We observed this issue when the joining user is on a slow or unstable network.
  • The joining client receives OPERATION_CANCELLED with reason RECONNECTING_MEETING.
  • At the same time, other participants may already see that user in the session.
  • The same user may appear again as a duplicate participant in the participant list.

How To Reproduce

  1. Use the Web Video SDK join flow:

    js

    await state.zmClient.join(meetingId, token, userName, passcode);

  2. App type / authentication method: Web Video SDK application using SDK token

  3. Simulate a slow or unstable network condition for the joining user.

  4. Attempt to join the session.

  5. In some cases, the joining client receives:

    JSON

    {"type":"OPERATION_CANCELLED","reason":"RECONNECTING_MEETING","errorCode":3}

  6. On other participants’ side, the same user may appear twice in the participant list.

  7. Environment:

    • Browsers: Chrome, Safari
    • Mostly observed on mobile devices
  • Session ID: ObJPZNd4Rb+r3vy3BRstYw==

Questions

  1. Is this expected behavior when the SDK enters reconnect flow during join?
  2. Why can other participants see the same user twice?
  3. Is there a recommended way to prevent duplicate participants in this scenario?
2

Hey @Dungvl76

Thanks for your feedback.

ObJPZNd4Rb+r3vy3BRstYw==

  1. Is this expected behavior when the SDK enters reconnect flow during join?

Indeed, we observed that one user had a very poor network connection, and joining the session took 123 seconds. By comparison, the other users in the session only took 2–4 seconds.

The OPERATION_CANCELLED error you mentioned is expected. Because this user was reconnecting due to network instability, some earlier operations such as startAudio were forcibly canceled and returned a rejected promise with OPERATION_CANCELLED.

  1. Why can other participants see the same user twice?
  2. Is there a recommended way to prevent duplicate participants in this scenario?

This is expected behavior. When a user disconnects from the server, they are not removed immediately. Instead, connectivity with the client is checked through heartbeat packets, and the user will only be removed if they have not reconnected for more than two minutes. This design is intended to improve the user experience by avoiding abrupt changes in the user list during brief network fluctuations.

For disconnected users, we also provide the isInFailover property on the participant object. You can refer to this document for handling that case: Event handling - Video SDK - Zoom Developer Docs

Thanks
Vic