Hub handshake failed with error 'WebSocket is not in the OPEN state' SignalR WebSockets Angular client with AutoReconnect() #17613
Comments
|
I think we need better logging in the WebSocketTransport.ts's WebSocket.onclose handler to see exactly what happened here. I don't see any log of the WebSocket CloseEvent details, though the logs that exist certainly imply the WebSocket closed shortly after it was open during the hub handshake. Given that the websocket closed during the hub handshake, it's not surprising that it took one more reconnect attempt to successfully reestablish the connection, though it would be nice to know why the WebSocket closed to begin whit. @paramitamandal can you reliably reproduce the handshake error? If so, is there any trick to make the repro reliable? If you could, putting the following log statement at the top of WebSocketTransport.ts's WebSocket.onclose handler might help diagnose the issue. this.logger.log(LogLevel.Trace, `WebSocket closed with status code: ${event.code} (${event.reason}).`); |
|
ok. thanks @halter73. This error occurred each and every time when client tries to reconnect with the Server after the server goes down. The first attempt always failed due to the handshaking error, and then in 2nd attempt connection established. I will put a log in webSocket.onclose() and let you know the feedback. |
|
We've seen some weird behavior with Angular's use of zone.js here, since it replaces the WebSocket class in JS with a different version. We should do an end-to-end angular test to see what we can find. |
|
@bradygaster to prove out the end-to-end |
|
I have already put some log as suggested by @halter73 but that did not add any other error log other than the previous one. |
|
@anurse there is no luck in non angular project also. same error everywhere. |
|
Can you tell us more about your hosting environment?
Also, can you capture a network trace? We have documentation on how to do this. It looks like something is causing the socket to be closed. Unfortunately the browser is somewhat unhelpful in these cases and doesn't give us a detailed error message, just "WebSocket is not in the OPEN state". |
|
We are using Win 10, 1809 x64. aprart from this we are using Win7, win 8.1, and server2016 and also other versions of Windows 10. |
|
The network trace: IEnwtrace1 - Copy.txt |
|
Hrm, looks like the WebSockets are very short-lived, but there's no real indication why it's being terminated in that trace (Browser dev tools traces have very limited WebSockets support unfortunately). Are you able to try using Fiddler or a tool like Wireshark? (If you're using Wireshark, it's best if you can do the trace over HTTP, and not HTTPS since decrypting the traffic with Wireshark is very difficult). Can you also collect server-side trace logs? Looking at the client-side logs and the trace you provided, it appears there isn't anything interrupting the connection there. |
analogrelay
added
the
Needs: Author Feedback
|
If you're using HTTPS you need to configure Fiddler to decrypt HTTPS traffic. All I see in that trace is encrypte TLS traffic and I can't decrypt it :(. Let me know if you have any more questions on how to assemble the necessary information. |
|
Here is the traffic captured by fiddler. Please let me know if this helps to investigate further or not. |
ghost
added
Needs: Attention 👋
|
How about server-side logs? Have you been able to collect those? |
|
I'm not able to find anything in the traces. Is it possible for you to share a runnable sample application that reproduces the problem? |
halter73
added
Needs: Author Feedback
|
I took a look at the fiddler trace too. The following request seems to be the reconnect attempt that failed. The trace shows the request only lasted a second and transferred a few bytes. The last WebSocket request happened 30 seconds later and seems to have stayed open until the end of the capture. I agree with Andrew. It would be super helpful to get a runnable sample that demonstrates the issue. Server-side trace logs might also be helpful. |
|
Just wanted to pinch in: We're experiencing the same behaviour in a react app using |
ghost
added
Needs: Attention 👋
|
@paramitamandal Ideally a git repo we can clone and run (with some steps you provide) to reproduce the issue. We can certainly try to reproduce this ourselves, but there may be a subtle difference that doesn't become clear until we're comparing code. If it's easy for you to set up a repro project then we don't lose a bunch of time to getting the correct scenario identified. |
halter73
removed
the
Needs: Attention 👋
halter73
added
the
Needs: Author Feedback
|
will give u the repo link soon. |
ghost
added
Needs: Attention 👋
analogrelay
added
Needs: Author Feedback
|
@halter73 @anurse You can use my repo to reproduce the issue |
|
This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. If it is closed, feel free to comment when you are able to provide the additional information and we will re-investigate. See our Issue Management Policies for more information. |
ghost
added
Needs: Attention 👋
|
@paramitamandal We've been a bit delayed due to the holidays but will take a look soon. |
|
@anurse no issue.. |
|
I have the same issue as described above, the first retry fails immediately with the message 'WebSocket is not in the OPEN state'. // build connection with retry policy
const connection = new HubConnectionBuilder()
.withUrl(url, options)
.withAutomaticReconnect(new InlineRetryPolicy(context => {
// the first retry fails with this message, but it is unclear why, if I retry immediatly after this, the connection succeeds
if (context.retryReason.message === 'WebSocket is not in the OPEN state') {
return 0;
} else {
observer.next({ state: HubConnectionState.Disconnected });
// when callback is called, start emitting state changes with the remaining seconds untill retry
RETRY_STREAM.pipe(map(x => ({ state: HubConnectionState.Reconnecting, seconds: RETRY_IN_SECONDS - x - 1 }))).subscribe(x => observer.next(x));
// return the amount of milliseconds the signalr library has to wait
return RETRY_IN_SECONDS * 1000;
}
}))
.build();So when that is the fail message, I reconnect directly, otherwise I do my normal retry logic, I don't like hacks/fixes like this, but I don't really know where the issue lies |
BrennanConroy
added
bug
|
Thanks, we can reproduce the issue and will look into the problem. |
Uh oh!
There was an error while loading. Please reload this page.
My application was first built on dotnetcore 2.2, then it was upgraded to dotnetcore 3.0 and it was working properly. But WithAutoReconnect() from Angular web app and all the default settings, gives following log:
The server is disconnected and client tries to reconnect. When server goes up and connected; then the following steps occurred:
And as result "Error: Connection disconnected with error 'WebSocket is not in the OPEN state'." is logged in the console.
These steps are consistency reproducible.
Please help me to get rid of this error in between 3rd and 4th retry attempt.
The text was updated successfully, but these errors were encountered: