-
Notifications
You must be signed in to change notification settings - Fork 100
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
Message containing the buffer is never received #74
Comments
What version of Erlang are you using? I have an uncomfortable feeling that this has to do with the rewritten There's actually a test for just the scenario you're talking about though. websockex/test/websockex_test.exs Lines 479 to 492 in fe7f22a
|
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.
|
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
The text was updated successfully, but these errors were encountered: