Chunk load error when deployed ("Something's wrong here")

[patrick-schneider-latori]

Currently we have a Hydrogen instance on production running via Netlify. On top of that, we are also fetching content from Storyblok. You can see the result on www.horando.de – the website itself runs smoothly and the metrics are very good. We love Hydrogen!

But we investigated an error, which comes up everytime we trigger a new deployment on Netlify. We are using webhooks on Storyblok and when content is published or unpublished, we always trigger a new build on Netlify. Sometimes, when there are a lot of changes, we have a higher amount of triggers in the queue. See the following screenshot:

If a deployment is ready, and you are opening up the website the first time, we see the following error:

In the console you can see a list of errors, the most interesting one is in the lowest position. If we click on it we see the following results:

I tried to find similar problems by googling it, but the only ones I found were two comments on Stackoverflow regarding the file hash key, which gets applied to the filenames and because of caching reasons the browsers expects an old hash key on the filename, which is not present anymore, because meanwhile the server already has newer files with newer hash keys (https://stackoverflow.com/questions/69300341/typeerror-failed-to-fetch-dynamically-imported-module-on-vue-vite-vanilla-set/74057337#74057337). But it is only my assumption here.

So like I said, this only happens when we trigger a new build. If you see the error page und just refresh the page, the error is gone, which leads me to think about that it might be a caching problem and the cache gets also refreshed while refreshing the website.

Any ideas to bugfix that? I already tried to set up a config where vite/rollup does not make us of hash keys, but then the website fully breaks.

I tried this in my vite config file:

build: {
  rollupOptions: {
    output: {
      entryFileNames: '[name].js',
      chunkFileNames: '[name].js',
      assetFileNames: `[name].[ext]`,
    },
  },
},

Any help or ideas are appreciated.

[davidhousedev]

I can say from first-hand experience that this is behavior is not specific to Hydrogen 😅. We see this all the time with a Gatsby app deployed on Netlify.

Netlify supports "atomic" deploys. In other words, when you deploy a new version of your site, all the static files from the prior deploy are no longer accessible. This proves problematic when you're deploying a client-heavy frontend because your index.html file, downloaded to the user's browser, doesn't get updated when you trigger a deploy. It has references to chunks that existed in the prior deploy and are no longer accessible.

The good news is that Remix is well-positioned to handle this from a framework perspective. I'm not sure if this is supported at the moment but the Remix client runtime could be configured to disable form submits via XHR and fall back to a full page form submit. When the full page submit resolves, the user will receive a new *.html with valid chunk references. Client-side navigation could also be configured to work the same way, where navigations would result in full-page reloads.

I've gotten pretty deep into this issue, it's common across frameworks deployed on Netlify.

[frandiox]

Yeah, it seems related to Netlify's CDN and asset invalidation.
Also, it looks like the project in this discussion uses Hydrogen v1. This repo is now for Hydrogen v2, based on Remix 😄
The v1 repo is here.

[patrick-schneider-latori]

Oh … sorry that I missed this part. But is this behavior really solved with Remix?

[patrick-schneider-latori]

Thanks to @davidhousedev for the statement. I might move this discussion also to Netlify, although I hoped someone knows a fix for this here. But thanks anyway to you both!

[davidhousedev]

Oh … sorry that I missed this part. But is this behavior really solved with Remix?

Not exactly solved, more that Remix is a great framework to solve this issue.

When we encounter this problem in Gatsby, we don't have a clear path forward because we need to get a new index.html but can't get one without a page refresh. We don't know when we can refresh the page, because someone might have client-side interactions that we'd lose if we refresh.

With Remix, all mutations are run on the server via actions. That means the server stores essential user state, and refreshing is always safe.

While you could just auto-refresh the page each time you catch a chunk load error, it's even better if you do so when a user takes an action like a link click or a form submit. Rather than having Remix's client runtime send that data async, it could send it via a full-page load with minimal impact to the user.