Debugging connection closed on 1006

[nicknotfun]

I've got a client of an internal tool who runs into ABNORMAL_CLOSURE / code=1006; and it's providing difficult to reproduce other than on his machine.

The debug log pattern is:

1. Connect to websocket
2. Log prints "sending 322 bytes"
3. Connection closed
4. Reader task finished.

I'll continue to investigate, but it would be very useful if we could eliminate any reason-lacking 1006 codes; for example knowing if it's a broken resource error vs. a client bug.

[belm0]

Looking at the code, it seems like this can only happen by Broken/ClosedResourceError. (_abort_web_socket() makes a 1006 without a reason string).

https://github.com/HyperionGray/trio-websocket/blob/da7e5fa32b12d241fa9ba2f01d9b682e88f4e1d5/trio_websocket/_impl.py#L1251-L1256

[cpiker]

I'm getting this error as well, python 3.8 on linux, trio_websocket version 0.11.1 installed via pip.

I only get this error when attempting to use an SSL context. Plain sockets work fine.

[joacortez]

I ran into the same issue. It seems to happen when there's an SSL error during the initial handshake. For me the hostnames were not valid.

Looking around I found that the error is caught inside the _reader_task, causing it to crash. The connect_websocket function waits for the _open_handshake Event, which is never set, because the handshake failed and the connection fails when the timeout is triggered.

Inside the _reader_task the handshake is initiated with an initial request . The SSL error is found when trying to send the request inside the _send function, as an BrokernResourceError. The __cause__ of this exception is an SSLCertVerificationError but it is not chained since the ConnectionClosed exception is raised from None.

I don't know if there's a clean way to catch the exception in the _reader_task and abort the connection and also give enough information about the error since currently the error is completely masked by a generic ConnectionClosed exception.

Changing what what your SSL context verifies during the handshake is a workaround. Although it is not ideal.