ItzCrazyKns
Do not kill entire chat window when websocket closes.
Reopens the websocket on close. Prevents badly configured reverse proxies from making the application stop working. In my testing, I've noticed that the websocket simply reopens when the connection is closed. Instead of setting error state to true on websocket close, we just clear the websocket out using the provided React setWs function.
In case of a valid reason from the backend, if the WS is closed then it would constantly try to reconnect and then the error message would pop up again and again so I cannot merge this.
Is there a way to communicate the reason then? There needs to be a better solution than just putting the entire page into error state.
Maybe exponential backoff? Attempt to reconnect immediately, then if it fails, back off for X seconds, then more seconds, and so on.
Alternatively, can check the error state when onClose. That will make it be able to prevent reconnect attempts if not just a normal close.
I wouldn't just close the entire PR, at least.
Alternatively, can check the error state when onClose. That will make it be able to prevent reconnect attempts if not just a normal close.
I wouldn't just close the entire PR, at least.
There are certain states when no error is being sent and the WS close
In that case, wouldn't we want to try immediate reconnection then? And exponential back off would handle that issue if we cannot reconnect.
Also, after testing this more locally by killing the backend server and thus the websocket connection, it doesn't appear to attempt to reconnect. But this test only covers a sudden connection drop from the backend.
Small update: Do not set connection to null if in error state. I'm still trying to work out the best way to do exponential backoff in the current architecture. Do you have any suggestions?
State does not gets updated instantly (they are asnyc without a callback), if the WS closes and the error state takes time to be set, the page would still be set to null and this would repeat
How about something like awaiting the setError, and then using setTimeout with a 0 interval to wait until the next event loop tick for checking the value?
How about something like
awaiting thesetError, and then usingsetTimeoutwith a 0 interval to wait until the next event loop tick for checking the value?
Wait won't work as it doesn't returns a callback function, the setTimeout method is not efficient, 0 ms interval it would check the value a lot of time and might suck the resources.
When using setTimeout with a delay of 0, it forces an execution on next event loop. It's kinda like process.nextTick in node. In any case, what is your suggested way?
Latest iteration has useRef for reconnecting websocket with exponential backoff. And as a side-note, I learned that useRef existed today.
@ItzCrazyKns, it makes no sense to close this pull request.
At the moment when the WS connection closes, you have to reload the page because it does not reconnect on its own.
I have the same problem on cloudflared connection - they close web sockets in 100 secunds, thus merging this PR would be very helpful for such scenarios.
@s-KaiNet, I've reimplemented this again at https://github.com/ItzCrazyKns/Perplexica/pull/555 But the author loves to close PRs instead of providing constructive feedback to the contributors. Let's hope for adequacy. Otherwise, we could just create a better project like this one.
@s-KaiNet, I've reimplemented this again at #555 But the author loves to close PRs instead of providing constructive feedback to the contributors. Let's hope for adequacy. Otherwise, we could just create a better project like this one.
Hey @realies,
I’m not against giving feedback or just closing PRs for no reason. I’ve shared feedback here and on other PRs too. The only ones I close without comments are super low effort or just small fixes like typos.
I kept this PR open so the author could try other ideas or ask for more info. I already left a comment earlier, so I was waiting to see if they needed help.
Just so you know, I work on this project in my free time. Some days I barely get any time at all. But I’m trying to keep Perplexica going and improving it. A lot of similar projects are abandoned, but I’m doing my best to keep this one alive and make it better.
I hope you get where I’m coming from...
Cheers
hey @ItzCrazyKns, but you just replied to the wrong person in your previous comment)) But on the topic... Great project and thank you very much for your efforts here! I can imagine how complicated it might be to manage fast-growing OSS project. This topic is very hot, so you might have even more problems with all the different PRs, issues and user requests, hopefully you will be able to handle it!