-
Notifications
You must be signed in to change notification settings - Fork 477
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
Conversation
* @param handler The handler being assigned. | ||
* @param eventListener The event listener to add. | ||
*/ | ||
removeEventListener(handler: string, eventListener: EventListener): void; |
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 }) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a comment
…at a builder's subclass does not get broken
29ad75b
to
6890779
Compare
testObjects.signalingClient.openConnection(testObjects.request); | ||
}); | ||
|
||
it('opens a new connection after closing the first one', done => { |
There was a problem hiding this comment.
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.
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 WebSocketclose
event, and creates a new WebSocket object. The issue was that theclose
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
⠀
Testing scenario 2: Reconnection when the WebSocket connectivity is not stable
Checklist:
Have you successfully run
npm run build:release
locally?Yes
Do you add, modify, or delete public API definitions? If yes, has that been reviewed and approved?
No
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.