PingPong / Graceful Restart sometimes throwing a fatal error error. #253
-
For future chads: the error below came frok the fact that the ws connection was not closing with an apropriate status this throwing a fatal error after which the connection could not be reset. In order to solve this i exported the websocket instance and used it in my index.js where inside a useEffect I would call socket.close(1000, 'normal close') whenever I would get my app in bacground, and on taking the app to foreground I would socket.close(4025, "Client Restart). For now it worked for me. Thanks, have a great day! Sometimes i am getting the following error: -on the client side:
-on the server side:
This is my setup client side implementation:
It usually works but sometimes it just throws this error. My guess is that when trying to close the connection and reestablish it the server invalidates the request due to an old subcriber id thus throwing this error. Any thoughts on where it might originate from or how I might be able to fix it? Thanks in advance! And thank you for the great work so far! EDITI looked at the recepie for ping pong again and saw that I was add ing unnecessary retryWait and lazy:true , took that out and added :
now a new error shows on the client side:
also i got this one a separate time 👍
Further explanation after i Take the app to background, leave it there for 20+ seconds , send a message from another device and take the app back to foreground I am not able to receive subscriptions until I move between screens. Another important thing to mention is that I client.resetStore() everytime i take my app to ferground in order to keep updated with the latest changes. client.resetStore() refetches all active queries (all queries from mounted components), I tried commenting it out and apparently after many tries still got the same error 👍
|
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 9 replies
-
Thanks for reporting, @CristianCiubancan, my time is a bit scarce now, but I will take a look at this as soon as possible.
This is very intentional, restarts will always have subscriptions re-subscribe with the same ID. That behavior should not cause any problems. In the meantime, since you have control over your server, you should absolutely use the server-side WebSocket protocol level pings and pongs, instead of the subprotocol pings and pongs from the recipe. One of the main reasons why subprotocol pings and pongs exist in the first place is because some servers dont implement the WebSocket protocol pings and pongs (like AWS). For such servers, the subprotocol pings and pongs is simply an escape hatch. Read more here: #201 and here: #117. Also, please read this comment to understand why client-side pings are not critical. One more thing you should know is that browsers often pause JavaScript when in background. WebSocket protocol level pings and pongs are built in all usable servers in
|
Beta Was this translation helpful? Give feedback.
-
Seems like the same problem that caused the server to send too big close frames (#243) was affecting the client. This has been fixed in Additionally, with @CristianCiubancan could you be so kind and update the version and try again? |
Beta Was this translation helpful? Give feedback.
Seems like the same problem that caused the server to send too big close frames (#243) was affecting the client. This has been fixed in
v5.5.5
.Additionally, with
v5.5.5
, the original close causing internal client error will be reported to error listeners, instead of the resulting close event. This allows for much better error handling.@CristianCiubancan could you be so kind and update the version and try again?