Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix vpn reconnecting issue #1993

Merged
merged 3 commits into from
Feb 8, 2022
Merged

Fix vpn reconnecting issue #1993

merged 3 commits into from
Feb 8, 2022

Conversation

simmkyu
Copy link
Contributor

@simmkyu simmkyu commented Feb 7, 2022

Issue #:
#1985

Description of changes:

  • During retries, the Chime SDK for JavaScript calls the WebSocket.close API on the previous WebSocket object, waits for the WebSocket close event, and creates a new WebSocket object. The issue was that the close event did not arrive in Chrome and Chromium environments when toggling WiFi on a VPN connection. (This behavior is reproducible in a minimal WebSocket app in Chrome 97.0.4692.99.)

    With this PR, SDK will continue creating a WebSocket if the WebSocket close event does not arrive for two seconds.

Testing:

Can these tested using a demo application? Please provide reproducible step-by-step instructions.

Testing scenario 1: Reconnection when the WebSocket connectivity is stable

  1. Open the Chime SDK serverless demo and join a meeting.
  2. Open the browser console and run the following script to force retrying the connection.
    app.audioVideo.audioVideoController.handleMeetingSessionStatus({
      isFailure: () => true,
      isTerminal: () => false,
      statusCode: () => 17,
      isAudioConnectionFailure: () => false,
      toString: () => 'Error',
    });
    
  3. Ensure that the attendee is present in the meeting.

Testing scenario 2: Reconnection when the WebSocket connectivity is not stable

  1. Connect to VPN.
  2. Open the Chime SDK serverless demo and join a meeting.
  3. Open the browser console and filter the console by transition. For example, you can type transition in the top input of the Chrome console.
    image
  4. Turn your WiFi off.
  5. Wait until SDK outputs the Reconnect message to the console. SDK starts to retry the connection due to no internet access.
    [INFO] SDK - transitioning from Connected to Connecting with Reconnect
    
  6. Turn your WiFi on. Ensure that your VPN is online again.
  7. Ensure that the attendee becomes present soon after VPN is online. Before this PR, SDK timed out and failed to reconnect to the session.

Checklist:

  1. Have you successfully run npm run build:release locally?
    Yes

  2. Do you add, modify, or delete public API definitions? If yes, has that been reviewed and approved?
    No

  3. Do you change the wire protocol, e.g. the request method? If yes, has that been reviewed and approved?
    No

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@simmkyu simmkyu requested a review from a team as a code owner February 7, 2022 23:48
* @param handler The handler being assigned.
* @param eventListener The event listener to add.
*/
removeEventListener(handler: string, eventListener: EventListener): void;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unnecessary probably but shouldn't this be optional ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A good catch!

};

// Remove the existing close handler to prevent SDK from opening a new connection.
this.webSocket?.removeEventListener('close', this.closeEventHandler);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to check for undefined/null webSocket here (as the check above in the if condition seems to assume it exists and same as the add below).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oops. Not this.webSocket? but I should've checked the existence of removeEventListener.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll add the /* istanbul ignore next */ since there's no point of testing a WebSocket object without removeEventListener. Builders cannot pass the custom WebSocket object.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should just mark these classes internal in next major version :)

this.webSocket.addEventListener('close', handler);
scheduler.start(() => {
handler(
new CloseEvent('close', { wasClean: false, code: 1006, reason: '', bubbles: false })
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we document what close code 1006 is and why we choose it here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a comment

testObjects.signalingClient.openConnection(testObjects.request);
});

it('opens a new connection after closing the first one', done => {
Copy link
Contributor Author

@simmkyu simmkyu Feb 8, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added one more test to ensure that SDK can open a connection twice without delay.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants