Fix websocket reconnect logic

[quthla]

The code is obsolete now that there is the improved auto reconnect function

It also did never actually work anyway. This will call listen with an undefined callback, thus leading to the following error and effectively preventing the client from reconnecting automatically.

TypeError: e is not a function WebSocketStore.ts:33:33

[codecov]

Codecov Report

Merging #242 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #242   +/-   ##
=======================================
  Coverage   90.87%   90.87%           
=======================================
  Files          43       43           
  Lines        1677     1677           
=======================================
  Hits         1524     1524           
  Misses         82       82           
  Partials       71       71

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9715eca...0df1f52. Read the comment docs.

[jmattheis]

Hey @quthla, thanks for your contribution!

It's a good catch but i don't think this code is obsolete. There are some miss configurations in which the web socket could be closed without having errors on any HTTP request. An example would be a wrongly configured reverse proxy which has a really small read/write/connection timeout. (see proxy_*_timeout settings in https://gotify.net/docs/nginx) In this case, the web socket would be closed without any reconnect.

Could we fix the existing implementation that we still do the reconnect and show the error message?

[quthla]

It will still call tryAuthenticate on close which fires the reconnect logic so that's not an issue and the code is not needed anymore

[jmattheis]

Are you sure? I think the reconnect logic (CurrentUser.connectionError) will only be executed if there was an error the first place (tryAuthenticate() will resolve successfully). In this case, only the web socket closed the rest of the state doesn't know of this and still thinks everything is fine.

[quthla]

Are you sure? I think the reconnect logic (CurrentUser.connectionError) will only be executed if there was an error the first place (tryAuthenticate() will resolve successfully). In this case, only the web socket closed the rest of the state doesn't know of this and still thinks everything is fine.

We can of course also keep the code.

[jmattheis]

It's not an obvious error, normal users doesn't look in the console for errors, so we don't know how frequent the bug occurs.

[quthla]

Well, if you want to keep it, then that's ok with me. After all, you know the backend and how all is tied together better than me.

I've restored and fixed the old code.

[jmattheis]

Perfect, thank you!

[quthla]

Can you make a new release? Maybe gotify will then finally reliably reconnect for me 😂

[jmattheis]

Do you use a reverse proxy? Gotify only closes the websocket connection if the user/client gets deleted, every other close should not happen.

[quthla]

I think it's more of a network issue which rarely occurs but yes I'm using a reverse proxy.

Checked my proxy's error logs but nothing there

[jmattheis]

Could you check the gotify log if there is something regarding websockets? Otherwise, it's most likely the fault of the reverse proxy. But, I'll create a new release after fixing #243

[quthla]

No results grepping for websocket. Grepping error yields a few hundred lines like the following

gotify | Error #01: you need to provide a valid access token or user credentials to access this api

[jmattheis]

That seems normal, I'll add some better error messages for websockets. With d764a8d messages like WebSocket: ReadError websocket: close 1006 (abnormal closure): unexpected EOF will be logged. This hopefully makes it clear, on which end the error occurs.

[jmattheis]

@quthla v2.0.12 is released https://github.com/gotify/server/releases/tag/v2.0.12

[quthla]

@jmattheis

gotify    | WebSocket: ReadError read tcp 172.17.0.3:80->172.17.0.1:52362: i/o timeout
gotify    | WebSocket: ReadError read tcp 172.17.0.3:80->172.17.0.1:52378: i/o timeout
gotify    | Error #01: you need to provide a valid access token or user credentials to access this api
gotify    | Error #01: you need to provide a valid access token or user credentials to access this api
gotify    | WebSocket: ReadError websocket: close 1006 (abnormal closure): unexpected EOF
gotify    | WebSocket: ReadError websocket: close 1006 (abnormal closure): unexpected EOF
gotify    | Error #01: you need to provide a valid access token or user credentials to access this api
gotify    | WebSocket: ReadError websocket: close 1006 (abnormal closure): unexpected EOF
gotify    | Error #01: you need to provide a valid access token or user credentials to access this api
gotify    | WebSocket: ReadError websocket: close 1006 (abnormal closure): unexpected EOF
gotify    | Error #01: you need to provide a valid access token or user credentials to access this api

[jmattheis]

@quthla Could you open a new issue for this and don't forget to include your nginx config.

[quthla]

I'm using Apache. So you suspect this to be an issue with gotify or why should I open a new issue?

[jmattheis]

Most likely not, but without the config I can't say it for sure. I don't want to discuss this issue in a pull request, therefore you've to create a new issue for it.