Loading chunk 1 failed.

[lewismoten]

Do you want to request a feature or report a bug?
bug

What is the current behavior?
On Internet Explorer 11, a request to a bundle in the cache results in "Loading chunk 1 failed.
If the current behavior is a bug, please provide the steps to reproduce.

1. Visit a website with almost 100 bundle files in the dist folder (3 are 11-18mb in size)
2. Visit the website a second time
3. See the network shows the chunk loaded with a 304 status code
4. See the console writes out a chunk failed (usually chunk 1)

{
"description": "Loading chunk 1 failed",
"message": "Loading chunk 1 failed.",
"name": "Error",
"stack": "Error: Loading chunk 1 failed.
  at PROMISE_THROWER (http://{domain-name}/{app-folder}/app/dist/bundle11152017111856.main.js:90254:42)
  at promiseReactionJob (http://{domain-name/{app-folder}/app/dist/bundle11152017111856.main.js:90279:9)
  at Anonymous function (http://{domain-name}/{app-folder}/app/dist/bundle11152017111856.main.js:90267:9)"
}

What is the expected behavior?
All bundles should load regardless if you have a status code of 304 (not modified)
If this is a feature request, what is motivation or use case for changing the behavior?

Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.
(This works fine in Chrome and MS Edge)

Internet Explorer 11.1770.14393.0
Windows 10
npm 3.10.10
node 6.12.0
webpack@^3.8.1
es5-shim@^4.5.9
es6-shim@^0.35.3

[lewismoten]

I'm digging a bit. I notice that with requireEnsure, script.timeout is set to 3 hours, 20 minutes (120000 seconds), and setTimeout is 2 minutes (120000 ms). Is there a way to configure the timeouts in webpack config?

[lewismoten]

I'm looking at the webpack/lib/JsonpMainTemplatePlguin.js file to diagnose what is going on. Currently the script.onload event is calling scriptComplete where installedChunks[chunkId] !== 0. (it's a promise) and this ends up throwing the new Error('Loading chunk ' + chunkId + ' failed.'));

[lewismoten]

More details... when the status code is 304 (not modified), the script.onerror event is calling scriptComplete.

[sokra]

I guess we used the wrong unit for script.timeout. Feel free to send a PR here to fix this.

Timeout is configurable with output.scriptTimeout.

[EugeneHlushko]

@sokra I can help but don't really get what you mean by configurable as the configurable value passed from options has to be milliseconds according to schema. In that case we need to do a local conversion of the value to seconds instead, otherwise its not fitting for setTimeout use anymore: https://github.com/webpack/webpack/blob/master/lib/JsonpMainTemplatePlugin.js#L54-L60

[lewismoten]

@sokra one of those values needs to be multiplied by either 1000 or .001, depending on which one you are modifying.

`script.timeout = ${chunkLoadTimeout * 0.001};`,

or

`var timeout = setTimeout(onScriptComplete, ${chunkLoadTimeout * 1000});`,

[sokra]

yep. I would keep the config value as milliseconds:

• It's not a breaking change
• setTimeout and other JS functions are in ms too

[lewismoten]

Before a change is made, I need to confirm that unit is seconds or milliseconds. I thought I saw something stating it is seconds, but I can't find documentation regarding the <script> element having a timeout property to begin with. The original bug here is unrelated as I suspect it seems to be memory related on the machine that registers large scripts as failing to load.

[EugeneHlushko]

@lewismoten script.timeout is set in seconds so do chunkLoadTimeout / 1000

[EugeneHlushko]

The setTimeout part should not be touched

[swASO]

Hi,
we have the same problem.

The original bug here is unrelated as I suspect it seems to be memory related on the machine that registers large scripts as failing to load.

can you explain this part a little bit more ?
we tried a little bit and everytime we get 304 as status code the chunk failed to load,
and that is not only on my machine

[sokra]

@swASO Which browser?

[swASO]

Chrome (v62) or DotNetBrowser ( based on Chromium v60)

[stylehuan]

me to

[gerdus]

Happens to me too, Firefox 57 on Windows with local static nginx. Works on Chrome.
Firefox devtools:

[EugeneHlushko]

Guys can you please set up a small reproduction repo, i could look into it this weekend. @stylehuan @gerdus @swASO

[gerdus]

just did a npm upgrade to webpack 3.10.0 and my problem seems to have been resolved.

[lewismoten]

No luck with webpack 3.10.0

[swASO]

i am not really sure if its really a webpack bug because we are using c# api with NancyFx and when nancy response 304 we get the chunk error ( other files, static files works with 304 ) but! when i use a little simple express server and the server response a 304 everything works fine.

so maybe someone can confirm my assumption

[wuchuguang]

var timeout = setTimeout(onScriptComplete, 120000);
// script.onerror = script.onload = onScriptComplete;
// function onScriptComplete() {

}

webpack.3.10.0
At the wrong sometimes : Loading chunk xx failed

[daizch]

Hi, I have the same problem too.
@lewismoten Did you resolve this problem?

[wuchuguang]

@gerdus i upgrade to webpack 3.10.0,but problem not resloved.

[simonewebdesign]

Same, it's still occurring in 3.10.0.

Has anybody managed to solve this issue?

[feibi]

so, has the bug been fixed?

[mc-zone]

Has fixed since 4.2.0 @feibi

[milewski]

im on version ^4.6.0 and getting Error: Loading CSS chunk 2 failed. and it doesnt work on firefox... (ok on chrome, safari)

the requested file is: static/css/home-page.6a695f91.chunk.js which get extracted as it refers to css. but i still have webpack trying to fetch this as a module.... somewhere...

[aleen42]

When testing under Fiefox 40 with Webpack@4.4.1, onScriptComplete has been marked as undefined and thrown a script error. It seemed wierd.

[kirillgroshkov]

I got here from https://forum.ionicframework.com/t/uncaught-in-promise-error-loading-chunk-20-failed/126937/51
wondering if it can be related...

[bluefirex]

I just encountered this issue out of the blue with absolutely no changes to dependencies or the code in a week. As is always with these problems, there seems to be no solution at all, so I tried just nuking node_modules and reinstalling and it fixed it.