[sockjs-client] fix exponential reconnect time

[carlosgeos]

• Operating System: Debian
• Node Version: v11.6.0
• NPM Version: 6.5.0
• webpack Version: 4.28.3
• webpack-dev-server Version: 3.1.14

• This is a bug

Code

You can see the problem here:
https://github.com/webpack/webpack-dev-server/blob/v3.1.14/client-src/default/socket.js

Expected Behavior

An exponential increase in time between reconnects with the sockjs server.

Actual Behavior

As you can see in the code I linked, the method onopen resets the retries variable to 0, so retries is always 0, and onclose always tries to reconnect waiting the minimum time. Therefore the 'infinite logspam' solution doesn't work and people experience what is depicted in #1604

Also, here (from #1604 as well):

How can we reproduce the behavior?

Make the sockjs server close the connection (for example because the client has a bad origin header), the client will try to reconnect forever without respecting the intended timeout.

It is obvious looking at the code anyway.

PR

I've already submitted a PR.

[alexander-akait]

@carlosgeos thanks for issue

[alexander-akait]

Should be fixed in v4

[amakhrov]

I don't see any related changes in the code, and it seems that v4 still keeps retrying indefinitely without any exponential backoff.
@alexander-akait could you please clarify?

[alexander-akait]

@amakhrov Can you check you have a latest version? If you still have a problem, please provide example how we can reproduce it

[amakhrov]

We're on 4.7.3

The exact scenario is webpack-dev-server terminating the socket, if it didn't receive the "pong" from the client as a part of heartbeat check.

[alexander-akait]

@amakhrov Maybe you can provide example? Also you can send a PR without tests (if you have solution), so I will look at code and try to search potential problem places

[amakhrov]

Now as I think further about the use case, I understand why retries do not work properly.

In this case a client socket successfully connects, but then the server terminates it (due to the lack of ping response). Every time a socket successfully connects, retries counter is reset - which is totally valid in other scenarios, but effectively disables the exponential retries logic for my case.

I'm not sure it's possible for the client socket to differentiate between the two cases, though