Loading chunk XYZ failed

[danielkcz]

There is a similar issue #4152, but the main difference is that I am not using a service worker just yet and it's a static deployment, no backend serving the content. This error did not make sense to me for a long time as I was unable to reproduce it, but yesterday it finally happened.

The scenario is quite a simple, there is a deployed app using code splitting (and React.lazy) which is loaded into browser except that some chunks are not yet loaded because they weren't needed before. If we deploy a new version later and suddenly user decides to go into the part of the app he wasn't before, it is looking for an older chunk that's not already there and 💥

I am wondering what is the proper solution to this. If there would be some way how to catch that error, I could force reload the app which ultimately is what needs to happen I suppose.

Honestly, I am a bit scared of registering service worker. The app is still heavy under development, but it's already in a production. Sadly there is nothing like release calendar on the team and it's not unusual to have 1-5 deployments to a production per week 🙄. Sometimes it's more or less a critical fix that should be delivered to customer ASAP. Is there some strategy to essentially detect that new version has been deployed and force the service worker to reload?

[ianschmitz]

A quick and easy solution is to actually leave old static assets on the server for an extended period. If you update your app, your old chunks should still be present, and users that haven't yet refreshed can still fetch the old chunks.

[danielkcz]

@ianschmitz Yea, I thought about that of course, but it adds extra overhead when preparing a release. How old assets should I keep there? When to remove the old ones or even recognize which are the old one in the mess of like 30+ chunks :)

[Timer]

The default behavior of skipWaiting: false is designed to prevent this exact bug. Have you changed it to true? Otherwise, this behavior sounds like a bug.

[Timer]

/cc @jeffposnick for visibility

[danielkcz]

Um, isn't skipWaiting part of the service worker? As I said, I am not using it just yet because of the mentioned reasons.

[jeffposnick]

The thing about lazy-loading failures is that they can be triggered by using a service worker with skipWaiting: true (which is not the case here), but they could also just be triggered without a service worker, during a redeploy when you're blowing away you're old set of versioned assets. Anyone who had a tab open with the old version of your app at that point, and then tries to lazy-load a versioned asset, will run into that problem.

I think a great course of action is for the folks who provide lazy-loading runtime code are upfront about these failure scenarios in their docs, and document patterns to work around them. The brute-force approach would be to force-reload the entire web page when there's a failure to lazy-load something. It looks like https://www.npmjs.com/package/react-lazy has some events you could hook into to detect failures, and respond appropriately.

[Timer]

Oh, derp. Sorry @FredyC I totally misread this. I thought you were using the service worker -- your first sentence clearly states otherwise. 😅
Sorry for roping you in, @jeffposnick!

I think this is a perfect scenario for turning on the service worker (because it solves this problem).
You should be able to listen for an update event and prompt the user to force reload, manually overriding skip waiting (I think you can do this).

[danielkcz]

Alright, thank both of you for the insight. I will probably try some skeleton app first and see if it behaves the way I need. In case it won't, I'll reopen this.