how to read/capture original error when doing using connect_async? about tokio-tungstenite HOT 6 CLOSED

Hm, we don't remove useful information from the original error as far as I can remember (so you can print an error if you map it in map_err for instance or handle it by any other means) and I don't remember having Other error with an empty error description. We also do not create any ErrorKind::Other errors explicitly. Could you check if you can establish a regular TCP / TLS connection to the server?

from tokio-tungstenite.

thanks for your reply.

Looks like I overlooked this and something else must be generating an error and dropping the original cause; I'll dig a bit further.

Sorry for the confusion.

from tokio-tungstenite.

I'm running into the exact same thing:

          match connect_async(url.clone()).await {
              Ok((mut ws_stream, _response)) => {
                  debug!("Connected to {}", url);
                  ...
              }
              Err(e) => {
                  debug!("Last OS Error: {}", Error::last_os_error());
                  debug!("Failed to connect to {:?}: {:?}", url, e);
                  Err(format!("connection failed: {:?}", e))
              }
          }

Trying to figure out what it was, I reported the last OS error (though I don't think it's the issue -- that just looks like a typical nonblocking connect result).

Last OS Error: Resource temporarily unavailable (os error 35)
Failed to connect to "<<redacted>>": Io(Custom { kind: Other, error: "" })

Even with full debugging enabled, I'm not seeing anything useful from tungstenite or hyper, which is a little surprising. Connecting to the websocket endpoint using openssl works as expected.

from tokio-tungstenite.

Discovered a bit more. This is happening when the endpoint returns a 404.

from tokio-tungstenite.

Hm, I believe that one of the underlying libraries does something fishy. The reason I think it's the case is because we don't create any customer errors with an empty error code inside tungstenite-rs. Is there a server which could be used to test / reproduce this behavior?

from tokio-tungstenite.

In my case it was something else, sorry for the confusion.
I fixed several things so I can't really tell you exactly what it was, but for sure it did not look like tokio-tungstenite was causing the issue.
thanks for the help!

from tokio-tungstenite.