rust-socketio
rust-socketio copied to clipboard
thread '<unnamed>' panicked at 'EngineIO Error'
I have the exact same issue as closed issue #166. Are there any updates? I am not sure why it was closed.
EDIT: Something else I noticed it that I don't receive events from the server anymore after some time.
EDIT: Something else I noticed it that I don't receive events from the server anymore after some time.
the thread which is respond to handle packet to callback is panic https://github.com/1c3t3a/rust-socketio/blob/main/socketio/src/client/builder.rs#L271
anything error about the underlying websocket connection will cause this thread panic
I wouldn't know what to do then. It works perfectly on the nodejs implementation of socketio. It happens so sudden, without any reason.
In software, nothing happens without any reason. The nodejs implementation contains logic for reconnecting when the underlying websocket connection is closed for some reason (laggy network or whatever). This implementation doesn't have such a logic, but @SSebo is currently working on it.
Oh, I didn't know that. I look forward to having that feature.
The error indicates that the WebSocket control frame was fragmented and invalid packet id 101, 105, 68, 44, 32 (maybe even more, they just seem to be added every time I edit this message), btw. Just thought it would maybe be helpful to know. I am just logging it instead of panic'ing for now, and that keeps it running for me, although I am probably not receiving all the data.
I even got 'thread '
All my issues seem to be entirely fixed after running the socket in a blocking allowed thread using tokio::task::spawn_blocking
method. I didn't really get an error message before to let me know that I had to do that, but now I did, so it might've been a recent push.
https://github.com/1c3t3a/rust-socketio/blob/4eea9b741caae207cf1f8c5df97022eb2b59d482/engineio/src/transports/websocket_secure.rs#L34
Nevermind. I actually got the error again after it running for like 7 hours.
@1c3t3a @milandekruijf maybe we should add some trace log.
This behaviour is now different with #229, this won't panic but rather try to reconnect on a transport error. I am closing this bug as it is outdated.