"[WDS] Disconnected" loop

[dennispg]

• Operating System: Windows 10 - 1809

• Node Version: v8.14.0

• NPM Version: 6.9.0

• webpack Version: 4.30.0

• webpack-dev-server Version: 3.3.1

• Browser version: Chrome 73.0.3683.103 (64-bit)

• This is a bug

• This is a modification request

Expected Behavior

Should not repeatedly reload the page after displaying [WDS] Disconnected.

Actual Behavior

Does not strictly happen every single time, sometimes it works. But more often than not, after making a change the hot reload will go into a loop reloading the page and displaying [WDS] Disconnected over and over.

It seems like two "o" sockjs msgs can be received during the same session, possibly when changes are recompiled in succession fast enough? This causes two socket opens, and when the second open request checks the readystate it is already open from the first request and so triggers a [WDS] Disconnect.

How can we reproduce the behavior?

A reproducible repo is available here:
https://github.com/dennispg/webpack-wds-disconnected-bug

1. run npm start, open https://localhost:9000/ in Chrome
2. find sockjs.js in the sources panel
3. add a breakpoint on line 933 which should look like: this._close(1006, 'Server lost session');
4. add some random semicolons in src/index.js over and over till the breakpoint hits. Try modify/save/modify/save in rapid succession for best results.

[alexander-akait]

Feel free to send a PR with fix

[dennispg]

I would love do to exactly that, however I have been unable to track down a proper fix on my own. I have tried, and this was the most I was able to find out. I will continue to research, but I worry that I need assistance to go any further.

I had hoped it would be helpful to provide a reproducible test repo in order to get some assistance at least in finding a solution. If creating a reproducible test repo is a waste of time though, please do let me know.

[alexander-akait]

I had hoped it would be helpful to provide a reproducible test repo in order to get some assistance at least in finding a solution. If creating a reproducible test repo is a waste of time though, please do let me know.

No, reproducible test repo allow to us fix problem very fast, i written Feel free to send a PR with fix because now it is weekends and you maybe want fix this asap so you can send a PR. We will fix this anyway.

[dennispg]

I completely understand, there is no rush for a fix. I just want to help find the solution, so I shared here. I will continue to research also.

[funwithtriangles]

I rolled back to webpack-dev-server 3.0.0 and webpack 4.20.2 and still experiencing this issue. I'm on Windows 10 (1803).

I'm wondering if it has something to do with having https enabled. I don't seem to be experiencing it once I set this option to false but this might also be due to the fact my page doesn't get as far without it.

Seems related: #851

[alexander-akait]

@funwithtriangles can you create minimum reproducible test repo, maybe you have other problem, thanks

[blackswanny]

have the same issue since updated from 2.x to 3.2 version with the update of webpack to 4.28.4

previously worked config for devServer:

{
      https: true,
      cert: options.https.cert,
      key: options.https.key
}

since in here https://webpack.js.org/configuration/dev-server/
I see the change to nest cert and key inside of https object, so the next config doesn't work as well:

{
      https: {
        cert: options.https.cert,
        key: options.https.key
      }
 }

this hammer also doesn't work:

     {
      headers:          { 'Access-Control-Allow-Origin': '*' },
      disableHostCheck: true,
      https: false
    }

here there is ca prop for https, what is this one? Do I need it also?
https://webpack.js.org/configuration/dev-server/

[alexander-akait]

 https: {
   ca: 'something',
   cert: options.https.cert,
   key: options.https.key
}

https://github.com/webpack/webpack-dev-server/blob/master/lib/utils/createConfig.js#L155

[blackswanny]

ok, thanks. I can find in code, just didn't get what it means. Seems it stands for specific cacert certificates. However it makes no difference. I rolled back to webpack-dev-server@2.11.5, sockjs@0.3.19 and the issue is still there. My chrome is 73.0.3683.103 and Firefox 66.0.3 . Chrome is still complaining and I have infinite loop of requests, which makes impossible to use dev tools as it is stuck processing those requests. However, Firefox stopped issue with old 2.11.5 version of webpack-dev-server. So it might be a mix of newly released Chrome and new version of sockjs or webpack-dev-server@3.x. Any ideas?