Webpack middleware/HMR errors or times out if multiple tabs open to localhost #518

New Issue

fergalmoran · 2025-08-09T17:16:36Z

fergalmoran commented

2025-08-09 17:16:36 +00:00

Originally created by @paulirwin on 8/10/2017

Using ASP.NET Core MVC targeting .NET Framework 4.6.2 and Microsoft.AspNetCore.SpaServices v1.1.1, and on the npm side aspnet-webpack 2.0.1, aspnet-webpack-react 3.0.0, webpack 2.7.0, and webpack-hot-middleware 2.18.2. OS is Windows 10, using Chrome 60 and VS2017 15.2, Node 8.2 and 8.3 both affected.

Steps to reproduce:

Launch a non-trivial ASP.NET Core / React / Webpack app while debugging in VS2017 using SpaServices, React, HMR, etc. Ensure you do not have any localhost tabs open in your browser (Chrome in this case). For appropriate scale, the webpack task when run from the command line takes about 9 seconds to run and generates a few MB of un-optimized JavaScript in non-production mode.
Ensure your webpack bundle builds and runs fine in the browser with a single localhost tab open.
Right click the tab in the browser and choose Duplicate tab. (Or in Firefox, copy the URL and open a new tab to that URL.)
Refresh either tab. Requests to the bundle files time out or return a 500 server error with no helpful information.
Close either tab and refresh the remaining open one. Bundle loads at normal speed as expected.

Multiple teams at my company working on entirely different products with no shared code have encountered this problem. They describe it as happening "sporadically", but I have now diagnosed it down to only happening when multiple tabs are open in your browser to the same localhost site with HMR connected. If you only have one localhost tab open it works great, more than one and it slows to a crawl, timing/erroring out for larger bundles. This appears to be some kind of race condition or deadlock. Confirmed that this happens in Firefox as well, so it appears to be something on the server side.

*Originally created by @paulirwin on 8/10/2017* Using ASP.NET Core MVC targeting .NET Framework 4.6.2 and Microsoft.AspNetCore.SpaServices v1.1.1, and on the npm side aspnet-webpack 2.0.1, aspnet-webpack-react 3.0.0, webpack 2.7.0, and webpack-hot-middleware 2.18.2. OS is Windows 10, using Chrome 60 and VS2017 15.2, Node 8.2 and 8.3 both affected. Steps to reproduce: 1. Launch a non-trivial ASP.NET Core / React / Webpack app while debugging in VS2017 using SpaServices, React, HMR, etc. Ensure you do not have any localhost tabs open in your browser (Chrome in this case). For appropriate scale, the webpack task when run from the command line takes about 9 seconds to run and generates a few MB of un-optimized JavaScript in non-production mode. 2. Ensure your webpack bundle builds and runs fine in the browser with a single localhost tab open. 3. Right click the tab in the browser and choose Duplicate tab. (Or in Firefox, copy the URL and open a new tab to that URL.) 4. Refresh either tab. Requests to the bundle files time out or return a 500 server error with no helpful information. 5. Close either tab and refresh the remaining open one. Bundle loads at normal speed as expected. Multiple teams at my company working on entirely different products with no shared code have encountered this problem. They describe it as happening "sporadically", but I have now diagnosed it down to only happening when multiple tabs are open in your browser to the same localhost site with HMR connected. If you only have one localhost tab open it works great, more than one and it slows to a crawl, timing/erroring out for larger bundles. This appears to be some kind of race condition or deadlock. Confirmed that this happens in Firefox as well, so it appears to be something on the server side.

fergalmoran closed this issue

2025-08-09 17:16:36 +00:00

fergalmoran referenced this issue

2025-08-09 17:19:09 +00:00

Streamed responses can be be Object or Stream #1177

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/JavaScriptServices#518