"[WDS] Disconnected" loop #1796

dennispg · 2019-04-13T07:22:27Z

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

run npm start, open https://localhost:9000/ in Chrome
find sockjs.js in the sources panel
add a breakpoint on line 933 which should look like: this._close(1006, 'Server lost session');
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.

The text was updated successfully, but these errors were encountered:

alexander-akait · 2019-04-13T15:07:04Z

Feel free to send a PR with fix

dennispg · 2019-04-13T15:46:14Z

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 · 2019-04-13T15:48:42Z

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 · 2019-04-13T16:18:34Z

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 · 2019-04-16T08:59:25Z

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 · 2019-04-16T10:19:53Z

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

blackswanny · 2019-04-16T23:04:27Z

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 · 2019-04-17T11:41:00Z

 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 · 2019-04-17T17:01:45Z

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 [email protected], [email protected] 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 [email protected]. Any ideas?

alexander-akait · 2019-04-17T18:12:57Z

@blackswanny can you create minimum reproducible test repo with 3 version, webpack-dev-server@2 is deprecated and can doesn't work

elesueur · 2019-05-06T18:46:04Z

@evilebottnawi I have this issue too, with SSL mode, in webpack-dev-server 3.3.1. It seems to have come along with Chrome 74. I don't think anything else in my environment changed. I see a failure in the first websocket connection (only for certain routes within my app! and the app reloads continuously). The websocket fails to connect with a timeout (error code 1006).

I applied the fix suggested in #851 (comment) to webpack-dev-server, and everything works fine.

I can send a merge request if desired. Unfortunately, I do not have a minimum reproduction.

FYI, I have my dev server running on a non-standard port with Angular CLI (port 4300 instead of port 4200, though this doesn't seem to make a difference), I have SSL enabled with a fully trusted self-signed cert, with a subject alternative name (which Chrome apparently desires now) and it is marked as fully trusted in Keychain Access app. I do not get any warnings when Chrome first loads the site. I have disableHostCheck set and my app runs on localhost.somedomain.com, which is set in my /etc/hosts file to 127.0.0.1.

ZebraFlesh · 2019-05-22T19:43:17Z

I'm seeing this consistently on both Mac and Windows 10 using Chrome 74, Safari 12.1.1, and Firefox 67. I was able to narrow things down a little: I was upgrading some stale dependencies and saw this error occur, so I restarted the dependency upgrades and was very methodical. This occurred when I jumped from webpack-dev-server 3.2.1 to 3.3.0 (with the corresponding required upgrade of webpack-cli from 3.2.3 to 3.3.2). I'm also extremely far from a minimum reproduction scenario.

My solution for now is to stick with webpack-dev-server 3.2.1 / webpack-cli 3.2.3.

alexander-akait · 2019-05-22T23:33:06Z

Don't stick version, it can be broken in future, please create minimum reproducible test repo

jsg2021 · 2019-05-28T19:11:05Z

If your dev server is behind a proxy, it might be sending requests to the wrong place. I was having a similar issue and solved it with defining public to be localhost:devserverport

alexander-akait · 2019-05-28T19:15:58Z

/cc @elesueur sorry for delay, we need this fix, can you send a PR?

blackswanny · 2019-05-29T00:42:15Z

fyi, I have it with Chrome( latest 74.x version), but I don't have it with Chrome Canary ( 76.x version). So may be something is with my code, but it is fixed in 76.x version of Chrome. Also Firefox and Safari seems to not reproduce it

ZebraFlesh · 2019-05-29T12:46:47Z

I see this consistently with both the release and canary channels of Chrome on Windows 10.

alexander-akait · 2019-05-29T13:05:08Z

@ZebraFlesh what do you mean?

ZebraFlesh · 2019-05-29T13:06:27Z

I'm saying it's not resolved by Chrome 76 as @blackswanny suggests

alexander-akait · 2019-05-29T13:32:12Z

@ZebraFlesh Can you create minimum reproducible test repo?

ZebraFlesh · 2019-05-29T13:51:47Z

Not easily, no. I've got a privately forked version of this repo: https://github.com/arabold/serverless-react-boilerplate/. It's using serverless framework with the serverless-offline plugin to exec a webpack-dev-server process. I'm not even sure where to begin on unraveling all that into something minimal. My suspicion is that offline environment is doing something that is unexpected by WDS, so "minimal" might still be "quite complicated".

alexander-akait · 2019-05-29T13:53:33Z

@ZebraFlesh bad, with reproducible test repo we will fix it very fast

dennispg · 2019-05-29T13:57:31Z

Just in case it was missed.. there has been a minimum reproducible repo available in the OP all this time.

ZebraFlesh · 2019-05-29T14:04:19Z

@ZebraFlesh bad, with reproducible test repo we will fix it very fast

I understand that. If I thought I could provide a minimal repo I would have already done so. But like I said, my failure case is quite far from minimal. If you think it would help, I’m happy to try and work it up.

alexander-akait · 2019-05-29T14:14:13Z

@ZebraFlesh can you send not minimal version? Sometimes impossible create minimum reproducible test repo

ZebraFlesh · 2019-05-29T14:48:18Z

This branch demonstrates the problem: https://github.com/ZebraFlesh/serverless-react-boilerplate/tree/wds-broken The last commit on that branch causes the issue we've been talking about (by upgrading to latest WDS); reset head to previous commit to get a working version.

To execute:

Make sure you have some AWS credentials set in your environment. This won't work without credentials.
1. If unfamiliar, fastest thing is to set AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in your current shell environment.
2. To obtain free credentials, see this stack overflow answer
Execute npm start
Visit http://localhost:300
Watch both the serverless offline output in your console and the browser console output go crazy with looping

alexander-akait · 2019-05-29T14:53:06Z

@ZebraFlesh thanks

dennispg · 2019-05-29T14:58:58Z

@ZebraFlesh out of curiosity, does the repo in the OP also have the same problem in your environment?
https://github.com/dennispg/webpack-wds-disconnected-bug

ZebraFlesh · 2019-05-30T00:35:06Z

@dennispg No, I couldn't make it break using the repo in the OP. I tried on macOS 10.14.5 with node 10.15.3 and Chrome 74.

funwithtriangles · 2019-05-30T13:08:08Z

Just for extra information, I stopped getting this issue but now I'm testing on iOS Safari and it is happening every time.

alexander-akait · 2019-05-30T13:09:53Z

Only on Safari?

funwithtriangles · 2019-05-30T14:09:09Z

Just tested in Chrome on iOS, same thing happening there. On Android it's fine. 🙁

alexander-akait · 2019-05-30T14:11:14Z

Only iOS? Sorry for many questions

funwithtriangles · 2019-05-30T14:13:03Z

Chrome on Android: ✔️
Chrome on iOS: ❌
Safari on iOS: ❌

funwithtriangles · 2019-05-31T12:16:22Z

So I have some sort of solution to this problem, which actually seems to be two problems for iOS. Firstly, there was an issue of the page refreshing really fast (#1370). This doesn't seem to be related to WDS but I managed to get past this issue following this advice: #1370 (comment)

However this lead me back to the WDS loop issue, which I seem to have solved by setting inline: false.

blackswanny · 2019-06-04T16:41:01Z

seems to be related
#1616

puru991 · 2020-07-03T08:09:00Z

If on a vps, Just do a yarn serve --public [your-public-ip-address], for eg. yarn serve --public 83.12.33.24
If on local, try setting public to either localhost or 127.0.0.1 (Although did not try on local)

sajidmansoori12 · 2021-03-24T10:42:25Z

Don't know how...but when I add the property injectClient:false to the devServer. The WDS disconnected stops showing up.

nefarioustim · 2021-04-30T06:24:11Z

This can generally be fixed by defining public. For some reason, WDS can't find the right address without it:

devServer: {
    https: true,
    port: 8080,
    public: "0.0.0.0:8080"
}

StevenBarquet · 2021-05-29T15:08:29Z

This can generally be fixed by defining public. For some reason, WDS can't find the right address without it:
devServer: {
    https: true,
    port: 8080,
    public: "0.0.0.0:8080"
}

Thanks I modified my config to this and it works:

devServer: { port: 3000, public: 'localhost:3000', }

alexander-akait · 2021-06-24T14:00:07Z

We refactor our code and in the next version you will have client.webSocketURL so you can setup right hostname/port/etc for proxyed dev server, also [WDS] Disconnected very often means you have invalid publicPath in webpack v5 we use auto (all assets are relative) by default, so it should happens very rare

erikmartinessanches · 2021-07-23T16:30:09Z

I'm getting this error in Chrome version 92.0.4515.107 and webpack-dev-server 3.11.1 created by npx create-react-app on http://localhost:3000/. Link to repository.

alexander-akait · 2021-07-23T16:32:50Z

it means you have invalid URL for sockjs, what is in your address bar in browser

erikmartinessanches · 2021-07-23T16:50:14Z

it means you have invalid URL for sockjs, what is in your address bar in browser

http://localhost:3000/

alexander-akait · 2021-07-23T16:51:32Z

But for web socket connection your are use 9090, so you got this problem, why do you use 3000 port? Your URL in address bar should be http://localhost:9090

erikmartinessanches · 2021-07-23T16:53:41Z

But for web socket connection your are use 9090, so you got this problem, why do you use 3000 port? Your URL in address bar should be http://localhost:9090

Thanks but I use port 3000 because of this:

If I use port 9090 I get "Unable to reach page" and only a crbug/1173575, non-JS module files deprecated.in the console.

alexander-akait · 2021-07-23T16:58:14Z

Something buggy in CRA... Sorry, I am afraid we can't fix it here, web socket address should be same as in address bar in browser, if you need proxy, you need more options for dev server, also please try PORT=9090 react-scripts start

erikmartinessanches · 2021-07-23T17:03:39Z

Something buggy in CRA... Sorry, I am afraid we can't fix it here, web socket address should be same as in address bar in browser, if you need proxy, you need more options for dev server, also please try PORT=9090 react-scripts start

Thanks, I'll open an issue with CRA. PORT=9090 react-scripts start didn't work for me, at least not in the root directory of the app. PORT=9090 yarn start did start serving on http://localhost:9090, but with the same error.

alexander-akait · 2021-07-23T17:07:59Z

weird, your repo works fine for me, check your env variables, run printenv if you on linux and check you don't have port variable or try to PORT=3000 react-scripts start

erikmartinessanches · 2021-07-23T21:37:27Z

No port variable visible when printenv. Tried PORT=3000 yarn start which also runs react-scripts, as I understand it. Interestingly, now the error is about port 9090: sockjs.js?9be2:1605 GET http://localhost:9090/sockjs-node/info?t=1627076185160 net::ERR_CONNECTION_REFUSED.

Tried with port 9090 and got this warning and a bunch of 404s:

WebSocket connection to 'ws://localhost:9090/sockjs-node/909/s0o2cyhv/websocket' failed: WebSocket is closed before the connection is established.

sockjs.js?9be2:1605 POST http://localhost:9090/sockjs-node/909/zorulcwl/xhr_streaming?t=1627076597133 404 (Not Found)
AbstractXHRObject._start @ sockjs.js?9be2:1605
eval @ sockjs.js?9be2:1494
setTimeout (async)
AbstractXHRObject @ sockjs.js?9be2:1493
XHRCorsObject @ sockjs.js?9be2:2871
XhrReceiver @ sockjs.js?9be2:2596
Polling._scheduleReceiver @ sockjs.js?9be2:2143
Polling @ sockjs.js?9be2:2135
SenderReceiver @ sockjs.js?9be2:2199
AjaxBasedTransport @ sockjs.js?9be2:1977
XhrStreamingTransport @ sockjs.js?9be2:3139
SockJS._connect @ sockjs.js?9be2:828
SockJS._transportClose @ sockjs.js?9be2:912
SockJS._transportTimeout @ sockjs.js?9be2:846
setTimeout (async)
SockJS._connect @ sockjs.js?9be2:822
SockJS._receiveInfo @ sockjs.js?9be2:802
g @ sockjs.js?9be2:66
EventEmitter.emit @ sockjs.js?9be2:86
eval @ sockjs.js?9be2:567
g @ sockjs.js?9be2:66
EventEmitter.emit @ sockjs.js?9be2:86
eval @ sockjs.js?9be2:374
g @ sockjs.js?9be2:66
EventEmitter.emit @ sockjs.js?9be2:86
xhr.onreadystatechange @ sockjs.js?9be2:1597
XMLHttpRequest.send (async)
AbstractXHRObject._start @ sockjs.js?9be2:1605
eval @ sockjs.js?9be2:1494
setTimeout (async)
AbstractXHRObject @ sockjs.js?9be2:1493
XHRCorsObject @ sockjs.js?9be2:2871
InfoAjax @ sockjs.js?9be2:356
InfoReceiver._getReceiver @ sockjs.js?9be2:539
InfoReceiver.doXhr @ sockjs.js?9be2:556
eval @ sockjs.js?9be2:525
setTimeout (async)
InfoReceiver @ sockjs.js?9be2:524
SockJS @ sockjs.js?9be2:730
initSocket @ socket.js?e29c:9
eval @ client?3a70:231
eval @ index.js?http://localhost:9090:271
./node_modules/webpack-dev-server/client/index.js?http://localhost:9090 @ sidebar.bundle.js:22027
__webpack_require__ @ sidebar.bundle.js:790
fn @ sidebar.bundle.js:101
1 @ sidebar.bundle.js:22878
__webpack_require__ @ sidebar.bundle.js:790
(anonymous) @ sidebar.bundle.js:857
(anonymous) @ sidebar.bundle.js:860
eventsource:1

I opened an issue on CRA.

alexander-akait added priority: 3 (important) scope: client scope: server severity: 3 (broken) type: bug labels Apr 13, 2019

gregveres mentioned this issue Apr 17, 2019

sockjs-node gives 404 after upgrade to v3. (wp v3 -> wpv4). wds not serving up html files #1802

Closed

1 task

aarongerig mentioned this issue May 1, 2019

dev-server default port is not added any more symfony/webpack-encore#565

Closed

manik1235 mentioned this issue Jul 12, 2020

cors manik1235/story_time#60

Open

alexander-akait closed this as completed Jun 24, 2021

"[WDS] Disconnected" loop #1796

"[WDS] Disconnected" loop #1796

Comments

dennispg commented Apr 13, 2019

Expected Behavior

Actual Behavior

How can we reproduce the behavior?

alexander-akait commented Apr 13, 2019

dennispg commented Apr 13, 2019

alexander-akait commented Apr 13, 2019 • edited Loading

dennispg commented Apr 13, 2019

funwithtriangles commented Apr 16, 2019

alexander-akait commented Apr 16, 2019

blackswanny commented Apr 16, 2019 • edited Loading

alexander-akait commented Apr 17, 2019

blackswanny commented Apr 17, 2019

alexander-akait commented Apr 17, 2019

elesueur commented May 6, 2019 • edited Loading

ZebraFlesh commented May 22, 2019

alexander-akait commented May 22, 2019

jsg2021 commented May 28, 2019

alexander-akait commented May 28, 2019

blackswanny commented May 29, 2019

ZebraFlesh commented May 29, 2019

alexander-akait commented May 29, 2019

ZebraFlesh commented May 29, 2019

alexander-akait commented May 29, 2019

ZebraFlesh commented May 29, 2019 • edited Loading

alexander-akait commented May 29, 2019

dennispg commented May 29, 2019

ZebraFlesh commented May 29, 2019

alexander-akait commented May 29, 2019

ZebraFlesh commented May 29, 2019

alexander-akait commented May 29, 2019

dennispg commented May 29, 2019

ZebraFlesh commented May 30, 2019

funwithtriangles commented May 30, 2019

alexander-akait commented May 30, 2019

funwithtriangles commented May 30, 2019 • edited Loading

alexander-akait commented May 30, 2019

funwithtriangles commented May 30, 2019

funwithtriangles commented May 31, 2019

blackswanny commented Jun 4, 2019

puru991 commented Jul 3, 2020

sajidmansoori12 commented Mar 24, 2021

nefarioustim commented Apr 30, 2021

StevenBarquet commented May 29, 2021 • edited Loading

alexander-akait commented Jun 24, 2021

erikmartinessanches commented Jul 23, 2021 • edited Loading

alexander-akait commented Jul 23, 2021

erikmartinessanches commented Jul 23, 2021

alexander-akait commented Jul 23, 2021 • edited Loading

erikmartinessanches commented Jul 23, 2021

alexander-akait commented Jul 23, 2021

erikmartinessanches commented Jul 23, 2021 • edited Loading

alexander-akait commented Jul 23, 2021

erikmartinessanches commented Jul 23, 2021 • edited Loading

alexander-akait commented Apr 13, 2019 •

edited

Loading

blackswanny commented Apr 16, 2019 •

edited

Loading

elesueur commented May 6, 2019 •

edited

Loading

ZebraFlesh commented May 29, 2019 •

edited

Loading

funwithtriangles commented May 30, 2019 •

edited

Loading

StevenBarquet commented May 29, 2021 •

edited

Loading

erikmartinessanches commented Jul 23, 2021 •

edited

Loading

alexander-akait commented Jul 23, 2021 •

edited

Loading

erikmartinessanches commented Jul 23, 2021 •

edited

Loading

erikmartinessanches commented Jul 23, 2021 •

edited

Loading