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: WebRTC uncaught promise rejection on incoming connection #2302

Merged
merged 2 commits into from
Dec 6, 2023

Conversation

achingbrain
Copy link
Member

We catch WebRTC errors, log them and throw normalised errors to ensure they are the same across WebRTC stacks (FF, Chrome, node).

#2299 made one of these operations async which would cause an UHPR if thrown.

Change checklist

  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation if necessary (this includes comments as well)
  • I have added tests that prove my fix is effective or that my feature works

We catch WebRTC errors, log them and throw normalised errors to ensure
they are the same across WebRTC stacks (FF, Chrome, node).

if thrown.
@achingbrain achingbrain requested a review from a team as a code owner December 5, 2023 18:51
log.trace('recipient connected, closing signaling stream')
await messageStream.unwrap().unwrap().close({
signal
})
Copy link
Member Author

Choose a reason for hiding this comment

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

This method is called from _onProtocol in transport.ts which handles closing/aborting the stream so there's no need to do it here.

@@ -20,8 +19,6 @@ export async function handleIncomingStream ({ peerConnection, stream, signal, co
const messageStream = pbStream(stream).pb(Message)

try {
const answerSentPromise: DeferredPromise<void> = pDefer()
Copy link
Member Author

Choose a reason for hiding this comment

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

No need for this, we can just await the promises returned by the WebRTC stack.

@@ -96,11 +87,6 @@ export async function handleIncomingStream ({ peerConnection, stream, signal, co
signal,
log
})
Copy link
Member

Choose a reason for hiding this comment

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

should we still log.trace('recipient connected, closing signaling stream') ?

Copy link
Member Author

Choose a reason for hiding this comment

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

I would have thought not, since this function isn't closing the signalling stream any more.

Copy link
Member

@SgtPooki SgtPooki Dec 6, 2023

Choose a reason for hiding this comment

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

I was thinking that we're still waiting for readCandidatesUntilConnected and the last log was "reading until connected", so in logs it could look like you're never done reading, nor connected, unless we see a "done reading" message

maybe my original comment should have asked for keeping log.trace('recipient connected, stopped reading')

peerConnection.setLocalDescription(answer).then(() => {
answerSentPromise.resolve()
}, err => {
await peerConnection.setLocalDescription(answer).catch(err => {
Copy link
Member

Choose a reason for hiding this comment

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

👍

@SgtPooki SgtPooki mentioned this pull request Dec 5, 2023
@achingbrain achingbrain merged commit d105061 into main Dec 6, 2023
22 checks passed
@achingbrain achingbrain deleted the fix/webrtc-uncaught-promise-rejection branch December 6, 2023 07:18
This was referenced Jan 18, 2024
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