-
Notifications
You must be signed in to change notification settings - Fork 155
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
Failed to execute 'setRemoteDescription' on 'RTCPeerConnection': The RTCPeerConnection's signalingState is 'closed'. #1050
Comments
thanks for the report! It looks like the PeerConnection went into a closed state without that triggering a reconnect (which it should). |
I'm using 2.0.3 on dev and 1.15.10 on prod. I can see this issue reported on both environments. We had our sentry disabled for some time, but I remember having this issue on older versions of sdk as well. We also get the same amount of errors like: I found this code:
It is executed when the I'll dig for more logs. |
Thanks for the insight, that means that the clients to perform a reconnect then after hitting that error? |
If it's not full reconnect, it will only do a signal reconnect. Maybe a pc reconnect at this point is better? Nevertheless, I could not find code that will do anything when I looked into logs from other events, but they all have the same error pattern from original post in common. |
Yeah, you're totally right. This code path failing should not be treated as a |
Thanks for the PR. I will update my project once it's released, and will report back if it fixed my problem. |
So, the changes did not help, I think they made the issue even worse, since now I get 3 unhandled exceptions instead of 1. I created #1063 to at least add a catch clause on those errors. This should at least make the errors handled and not be reported by sentry, which helps my case. This won't help with the issue itself, however. |
Hey, I think we should close this one for now.. I thought that the fix went into the latest release somehow, I even read the release notes, and I swear I saw that PR in there. |
were you able to test the changes in the latest release? |
yes, the error is still present. From error trace I can see that it's coming from callbacks added in setupSignalClientCallbacks() |
could you provide the exact error and stack trace of an error that was raised in the version released yesterday ( |
The exact stack trace looks like this:
As you can see, not much of a stacktrace on this error, because ts wrapped it in a generator. If I look into code, I see this at where the error was thrown:
Which leads me to: Looking into livekit's console logs:
Then
|
Right after error on
It originates in |
Thanks! How do the client logs continue after the |
Hm, that's a good question. Unfortunately, we don't have tracking of what's happening after the error, I'm not even sure if this is possible with sentry. But, a good thing is that there are only 1 such error reported, not 3 of them consecutively, like I saw before. |
It would be great if we were to replicate this issue in an isolated manner. Any hints on what kind of client (OS + browser combination) runs into this most frequently or what might be causing this reconnect pattern in the first place? |
I think this is somehow connected to the server. E.g. room migrates, or lk server becomes unavailable for some reason and shutdowns abruptly. As for the browser, I see that it happens on chrome / edge, on windows, mac and even linux. The livekit-server we use is 1.5.0 |
@HermanBilous I'll close this issue for now. We haven't heard any similar reports. If you're still seeing this issue with the latest client+server versions feel free to let me know and I'll reopen it. |
Describe the bug
I have this issue that I cannot reproduce at all, but get a lot of errors in sentry for. Could you please take a look and point in a direction to how to fix it. Here's the log I can extract from sentry.
Reproduction
N/A
Logs
Severity
annoyance
Additional Information
No response
The text was updated successfully, but these errors were encountered: