Open Awlexus opened 5 years ago
What version of Erlang are you using?
I have an uncomfortable feeling that this has to do with the rewritten :ssl
module.
There's actually a test for just the scenario you're talking about though.
Erlang v22, but I've had this issue since ~v21.3
Sent from my K10 using FastHub-Libre
So I tried running the test, but some of them failed, because of a tsl_alert. The one you mentioned was one of the failed tests.
6) test handles a ssl message send right after connecting (WebSockexTest)
test/websockex_test.exs:479
** (MatchError) no match of right hand side value: {:error, %WebSockex.ConnError{original: {:tls_alert, {:insufficient_security, 'received SERVER ALERT: Fatal - Insufficient Security'}}}}
code: {:ok, _pid} = TestClient.start_link(url, %{})
stacktrace:
test/websockex_test.exs:484: (test)
The following output was logged:
03:04:51.707 [info] TLS server: In state hello at ssl_handshake.erl:1343 generated SERVER ALERT: Fatal - Insufficient Security - no_suitable_signature_algorithm
03:04:51.715 [info] TLS client: In state hello received SERVER ALERT: Fatal - Insufficient Security
Hi, I've been investing a bug that caused multiple discord clients to malfunction.
I think I've tracked the reason to the fact that the task that is started in
open_connection/3
is supposed to send the buffer inhandle_response/1
, but it is send to the task instead. Therefore the websocket process waits until the:ssl_close
message closes the socket due to inactivity.I don't understand, how did that work in the first place? Did I miss something?
At least that's what happens, whenever connection times out. While writing this issue I got a lucky attempt where it connected immediatelly and I saw that the buffer returned from the successful attempt was empty. During all unsuccessful attempts the second frame was already in the buffer, so I thought this was the norm, but it seems that the buffer is lost, because the task is sending the buffer to itself instead of the Websocket process