Service worker fails to load new dynamic/code-split chunk

[TheHolyWaffle]

Is this a bug report?

Yes

Can you also reproduce the problem with npm 4.x?

Yes

Which terms did you search for in User Guide?

progressive web app service workers

Environment

1. node -v: 8.4.0
2. npm -v: 5.6.0
3. yarn --version (if you use Yarn):
4. npm ls react-scripts (if you haven’t ejected): 1.0.17

Then, specify:

1. Operating system: Windows 10
2. Browser and version (if relevant): Chrome 63

Steps to Reproduce

1. Set up a default CRA project
2. Install react-loadable to code-split a certain React component on the page
3. Build, serve and navigate to the page
4. Modify the component earlier (to change the generated hash)
5. Build, serve and reload the page

Expected Behavior

The new version of the code-splitted component should be loaded correctly.

Actual Behavior

The installed service worker tries to fetch the old component chunk instead of the new one, resulting in a failure to load the new chunk. This is because the hash has changed since the last time the service worker was installed. Because of this react-loadable interprets the error and refuses to display the new page, resulting in a blank page.

This is less than ideal, and the only thing I could come up is to force a reload on the homepage. This will trigger the new service worker to be installed which results in the correct component/chunk being loaded.

[engmyahya]

@TheHolyWaffle try use the following webpack.config.js

var path = require('path');
var webpack = require('webpack');

module.exports = {
  context: path.join(__dirname, 'app'),
  entry: ['./index.html', './index.js'],
  output: { 
    path: path.join(__dirname, 'dist'),
    filename: 'bundle.js'
  },
  module: {
    loaders: [
      {
        test: /.js?$/,
        loader: 'babel-loader',
        exclude: /node_modules/,
        query: {
          presets: ['es2015', 'react']
        }
      },
      {
        test: /\.html$/,
        loader: "file-loader?name=[name].[ext]",
      },
      {
        test: /\.css$/, 
        loader: "style-loader!css-loader" 
      },
      { 
        test: /\.png$/, 
        loader: "url-loader?limit=100000" 
      },
      { 
        test: /\.jpg$/, 
        loader: "file-loader" 
      }
    ]
  },
  devServer: {
    historyApiFallback: true
  }
};

[TheHolyWaffle]

@engmyahya How would that help? I see nothing special sticking out from that webpack config that would fix this issue.

[TheHolyWaffle]

@jeffposnick would you be able to tell what is going wrong here?

I have explicitly removed any cache headers from service-worker.js and index.html but to no avail.

[TarikHuber]

I have the exact same issue. "Solved" it also with reloading the page. But dosn't feel like a real solution.

[jeffposnick]

I don't believe that this type of failure is limited to scenarios in which there's a service worker installed. For instance, you could imagine a scenario in which a long-lived single page app not controlled by a service worker attempts to dynamically load a hashed chunk as a result of a SPA-style navigation, but the URL for that chunk is no longer valid because the assets for the site have been updated and redeployed in the interim.

So, while there are ways to avoid getting into this state by modifying the service worker's behavior[*], I wonder if it would just make more sense to address it from the perspective of solving the non-service worker scenario as well.

One approach would be to detect when there's a failure to dynamically load one of the chunks that's needed to perform an SPA-style navigation and use that as a cue to trigger a "real" navigation request, which should recreate the DOM and get the client to the point where it's expecting the hashed chunk names that correspond to what's currently on the server.

I'm not familiar with the libraries you're using to dynamically load the chunks, but perhaps someone who knows more about that would have specific guidance as to the code changes that would be needed.

[*] Setting skipWaiting: false when generating the service worker should prevent the old caches from being purged until all open tabs that are controlled by the service worker have been unloaded, but the drawback of using that config is that developers who expect to see new content when they reload an open tab will have to wait until they close and reopen the tab instead.

[ugogo]

I went into the same scenario as TheHolyWaffle.
Calling unregister instead of register of registerServiceWorker fixed the thing, but it has broken our production for days, and recovering from this is really painful

[jeffposnick]

@ugogo But again, isn't this a problem that you need to solve whenever you deploy a long-lived web app that relies on loading in chunks dynamically at runtime that might have been removed from the web server?

You mentioned that you've unregister()ed your service workers, which is fine, but what about the possibility of this occurring without service worker involvement?

[ugogo]

@jeffposnick Yeah I think you're right, chunks were removed from the server, which was leading to a 404.
unregister() was only used to keep our production safe before finding the correct solution 😄

[uditalias]

+1
I have the exact same issue

I have an "app shell" with split points for each container/page:
for example:

• App Shell - contains app header and main router
  • Dashboard - split point
  • Report - split point
  • Account - split point
  • Settings - split point

Some times when i'm deploying my app im getting an error saying a chunk can't be loaded.
The error disappears after a refresh.

[jeffposnick]

The change in https://github.com/facebook/create-react-app/pull/3924/files#diff-d2bddbd3bfb7051f9381474c844674faR446 should help avoid issues with lazy-loading for developers who use service workers via create-react-app.

But as mentioned previously, independent of the service worker, this is a problem you need to deal with any time you're lazy-loading versioned assets. How would you avoid it if you're just in a scenario in which a user has a tab open for an extended period of time (without a service worker registered), and then they attempt to load a versioned asset which has been removed from the server in the interim?

Add in logic into your lazy-loading code that handles failures by, e.g., automatically performing a full-refresh, or at least showing a meaningful error to your users so that they could manually refresh, seems like it would be necessary in general.