[edge] Deployment of new version breaking site for live users. ( Loading chunk {n} failed error)

[aldarund]

Version

v1.4.0

Reproduction link

None

Steps to reproduce

This happens on a live site, production deployed not a dev. The sequence of events following:

User opened the site home page
New version of the app was deployed to web servers
User clicked a link to another page within the nuxt SPA
User saw Loading chunk {n} failed message instead of the new page content
https://i.imgur.com/AO7gX9h.png

Any site deploy could break the SPA for live users and cause them to need a refresh.

This should be handled properly by nuxt, maybe something like automatically refresh in such cases. This is just really frustrating and bad behavior for users

What is expected ?

No error displayed to user. Site autoreload or whatever will work here

What is actually happening?

User see some cryptic error

Afaik nuxt 1.4 have same behaviour

_{This bug report is available on Nuxt.js community (#c7171)}

[lucasmpaim]

Any update on this?

[aldarund]

@lucasmpaim you can use workaround like this for now -> #742 (comment)

[Atinux]

Everytime you will rebuild your app, some filenames will change, the solution is to push your bundle to a CDN to avoid having not found file which lead a a chunk error.

We may try to find a solution to hard-reload the page when this error happens, any PR attemps will be really appreciated :)

[qm3ster]

@Atinux what are you talking about, "hard-reload" 😱
Only seamless hotModuleReloading without memory leaks and with Vuex migration!

[amorino]

Any update on this?

[ahus1]

For now I use the following workaround by adding this to the error template: it will reload the page. The user will be again on the page where she/he started the navigation. She/he can then retry the interaction.

It adds a hash to the URL to avoid infinite reloads. The hash will be automatically removed on the next successful navigation.

This will might work for you as well until #3940 is released. Tested with Nuxt 2.2, but should work with earlier versions as well.

    mounted: function () {
      if (this.error.statusCode === 500
        && /^Loading chunk [0-9]+ failed/.test(this.error.message)
        && window.location.hash !== '#retry') {
        // the chunk might no longer be available due to a recent redeployment of the page
        // mark the page to don't trigger reload infinitely
        window.location.hash = '#retry'
        window.location.reload(true)
      } 

Comments to improve the workaround are welcome!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[sumeshkmp]

Have seen this issue on V2.2.0

[magisters-cc]

Up, one more.

[josepjaume]

This is definitely an issue.

[purpleow1]

Is this issue fixed in version 2.4.0?

[ahus1]

yes (i tried it, the nuxt SPA will reload once it doesn't find a JavaScript resource it tries to load. This way it will load the most recent app from the server that will have all needed resources available)

[ameistad]

I'm experiencing this on Nuxt version 2.4.5, but only in development.

[unr]

Currently experiencing this live on 2.4.5

Previously, I had used this error/refresh solution

But this no longer seems to work? I'm simply having errors logged about chunks again, and I can't seem to get this working.

---

On the topic of putting nuxt files on a CDN..., how would that work with globally distributed lamdas like now.sh?

[buremba]

@robyedlin Ideally, Nuxt can load all chunks into the browser's cache so that the user doesn't need to reload the page. There might be a service worker in the background that checks the new version and pushes a notification to the user to reload the page in order to update to the latest version. In fact, there are few apps that follow this approach. See https://medium.com/progressive-web-apps/pwa-create-a-new-update-available-notification-using-service-workers-18be9168d717

[robyedlin]

@buremba This is actually how nuxt spa mode works, so an option to allow this in universal mode might be cool.

@Atinux what do you think about a universal mode config option that allows downloading all js chunks async on first page load, similar to the way it works in spa mode? This would mitigate almost all loading chunk errors.

[buremba]

I did not know about the PWA before, just started experimenting it for this use-case. Couldn't find any relevant information here though. https://pwa.nuxtjs.org/

[josepjaume]

I kind of fixed this in the past by checking for a version file containing the SHA of the latest commit in the background, and then setting an updated state in the store if changed. Then I hooked into the router to check if updated was set, and instead of changing routes on the client-side, the app resorted to regular navigation, reloading the app "seamlessly".

Ugly hack, but it worked. Sure there's better ways to do this though.

[garineGiftagram]

OK so files starting with . will give 404 not found error. This is happening to me with nested routes. Not sure what the solution is for now.

[AndrewBogdanovTSS]

@garineGiftagram why do you need to call your routes starting with . ?

[garineGiftagram]

@AndrewBogdanovTSS chunks/code splitting are created by my dynamic routes.

Check my stackoverflow Question
https://stackoverflow.com/questions/59292564/nuxt-js-npm-run-build-results-in-some-js-files-being-not-found

[AndrewBogdanovTSS]

@garineGiftagram from the link I understood that the problem is not in generation but in the filename, there shouldn't be cases when your file don't have a name. You could at least put cache in front of it. Did you find what was causing empty names issue?

[garineGiftagram]

@AndrewBogdanovTSS even when I change the filename settings in the config , this one particular file did not get updated. whatever I did, I just got .234dfg.js But I fixed the issue by changing nuxt config as in the stackoverflow answer. thanks for the help though.

[khangal]

For now I use the following workaround by adding this to the error template: it will reload the page. The user will be again on the page where she/he started the navigation. She/he can then retry the interaction.

It adds a hash to the URL to avoid infinite reloads. The hash will be automatically removed on the next successful navigation.

This will might work for you as well until #3940 is released. Tested with Nuxt 2.2, but should work with earlier versions as well.

    mounted: function () {
      if (this.error.statusCode === 500
        && /^Loading chunk [0-9]+ failed/.test(this.error.message)
        && window.location.hash !== '#retry') {
        // the chunk might no longer be available due to a recent redeployment of the page
        // mark the page to don't trigger reload infinitely
        window.location.hash = '#retry'
        window.location.reload(true)
      } 

Comments to improve the workaround are welcome!

This workaround is not working because layouts/error.vue is not rendered.
nuxt version: 2.11.0
build command: yarn generate

[cain]

@pi0 is it possible to get this issue reopened?

[cain]

@khangal Please let me know if you find a workaround :)

[gabrielsze]

I received this same error on production build as well. Wanting to know if there's a good fix for this.

[pi0]

Hi. It is expected that #3940 to be working and trigger a hard reload if a chunk is missing. Do you mind opening a new issue (with proper steps to reproduce) describing in what situation error can't be handled?

[yuchiko]

Hi. It is expected that #3940 to be working and trigger a hard reload if a chunk is missing. Do you mind opening a new issue (with proper steps to reproduce) describing in what situation error can't be handled?

@pi0 As I understood you fixed chunk errors only for css files. Did you have a reason for this ? Cause right now I have an error with js files with "@nuxt/core@2.12.2":

I thought to add a reload for js chunks files or try to keep all chunks from the previous 1-2 releases.

[guska8]

still happening on nuxt 2.14.7

[reinoldus]

Has this been fixed? I keep getting the same error

[vivianifederico]

Do you have any update on this topic? we had to put in place a terrible workaround in order to avoid this situation.

[guska8]

We discovered that in our case the problem was the cache expiration time from cloudfront when serving the nuxt static build from amazon S3. When we changed the cache expiration time to 0 if i'm not wrong, the problem went away forever. Best regards

[Bruno-Meowtel]

Just FYI, we were experiencing the same issue and found an article listing all the possible workarounds:
https://imrecsige.dev/garden/how-to-solve-missing-chunk-code-splitting-errors-after-deploy/

We will most likely go with the Websocket way on our end, but the Cache approach would work as well unless you have a time-sensitive update to deploy.

[kingychiu]

Thanks @guska8 for the solution. I fixed my problem on CloudFront as well. Let's me share it in details here.

Context:
First of all, I am deploying an SSR Nuxt.js application on AWS ECS (Fargate), for those who have experience with CDK, I am using aws_ecs_patterns.ApplicationLoadBalancedFargateService. Overall I have the following:

Route53 -> CloudFront -> EC2 Application Loadbalancer -> ECS (Fargate) <- ECR <- CodePipeline <- Github

Problem:
During the deployment, the code is pulled from GitHub and uploaded to ECR as a Docker Image; when the service with the old code is killed, the old assets (JS, CSS, Images) are gone. It is because all the assets' filename are hashed, the new assets won't have the same filename. Any users with the old version of the web app will hit 404 errors when their old web app requests some old assets.

Based on @Bruno-Meowtel website above, this should not be an issue because I have a CDN (CloudFront here). But by default, CloudFront has a setting of Minimum TTL: 1 sec. As a result, the old assets got removed from the CDN too quickly.

Solution:
The idea is basically the "Keep old versions" solution from the page @Bruno-Meowtel shared above.

Setting MinTTL to a large number fixes my issue. In particular, I have the following CloudFront setup:

MinTTL Documenation

I only cache the assets folder of my Nuxt.js app and disable caching of the pages:

There are 2 reasons why the pages are not cached:

1. I am using server-side authentication; if the CDN caches the pages, it will cache the authenticated pages... (with other users' information on it), which is super bad
2. This way, the HTML is not cached; only the JS, CSS, etc are cached, an updated version of the web app can be released quickly. Because the HTML is not cached, as long as the user got the latest HTML, they will get the latest assets.

The HashedAssetsCache policy is a customized policy with a large Minimum TTL.