question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Cached SW index.html gets a 404 error on old bundle

See original GitHub issue

Is this a bug report?

Yes

Did you try recovering your dependencies?

Yes, happened on multiple deployments.

Which terms did you search for in User Guide?

Read the parts about service worker and also searched for similar issues, found this one: https://github.com/facebookincubator/create-react-app/issues/3613 but that was about chunking, which I do not use.

Environment

  1. node -v: 9.4.0
  2. npm -v: 5.6.0
  3. yarn --version (if you use Yarn): 1.3.2
  4. npm ls react-scripts (if you haven’t ejected): n/a

Then, specify:

  1. Operating system: Mac OS High Sierra
  2. Browser and version (if relevant): Google Chrome 63

Expected Behavior

When I deploy a new version of my application I expect it to load the old HTML and load the old JS bundle from it’s cache. If that’s no longer available (for whatever reason) it should fetch the new HTML and with that also the new JS bundle.

Actual Behavior

The service worker serves the old index.html, but it tries to get the JS bundle from the server. Because a new version has been deployed that bundle is no longer there, so it receives a 404 error, resulting in a white (broken) page. Refreshing the page fixes the issue.

The contents of my index.js

// @flow
import React from 'react';
import ReactDOM from 'react-dom';
import registerServiceWorker from './registerServiceWorker';

import Organisation from './apps/organisation';

const release = process.env.REACT_APP_GIT_COMMIT;

// Set up Sentry
if (process.env.NODE_ENV !== 'development') {
  window.Raven.config(
    'https://secret@sentry.io/secret',
    { release },
  ).install();
}

console.log(`Commit: ${String(release)}`);

const element = document.getElementById('root');

if (element) {
  ReactDOM.render(<Organisation />, element);
}

registerServiceWorker();

Here screenshots of the network tab during the ‘broken state’

screen shot 2018-01-21 at 00 57 49 screen shot 2018-01-21 at 00 58 10

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Comments:20 (12 by maintainers)

github_iconTop GitHub Comments

4reactions
nfantonecommented, Oct 4, 2018

@Timer I hit this very same issue today after deployment using latest CRA 2.0.4 and the new Workbox service worker script.

image

Manually unregistering the worker and refreshing makes the site load, but any subsequent refreshes just crashes it again for me.

Used to work just fine with previous versions, mind you (sw-precache).

I believe this issue should be re-opened.

EDIT For what I’ve been gathering around, this seems to be related to chunk sizes - however, my app’s chunks are actually quite small:

  294.54 KB  build/static/js/1.7199b771.chunk.js
  49.06 KB   build/static/js/main.2c86934a.chunk.js
  21.38 KB   build/static/css/main.ff66eee3.chunk.css
  1.6 KB     build/static/css/1.fdfa198a.chunk.css

As you can see from the names of the chunks resulting from the build and the ones being fetched from the worker (screenshot), service-worker.js tries to load a different version every time (cc. @jeffposnick)

I’m at a loss here, at the moment.

3reactions
rovansteencommented, Feb 2, 2018

@jeffposnick I’m not sure how I can see the unminified file size with create-react-app but I can confirm that code splitting fixed this problem. I think it’s a good thing that large files are not downloaded for offline usage but it would be good to show the message if the file size is too large. I now have to manually check the service-worker.js before deploying to make sure that all chunks are in there because if they don’t my site breaks on the next deployment. @gaearon would it be possible to show that message?

Read more comments on GitHub >

github_iconTop Results From Across the Web

Why 404.html causes uncaught error during service worker ...
Cache.addAll() is an all or nothing API. If any response is not in the 200 HTTP status code range, nothing will be cached....
Read more >
Handle loading errors & fallback with HtmlWebpackPlugin
In index.html file create a message listener from serviceworker, if message is fail chunks then reload the page with clearing the cache at...
Read more >
Service Workers Break the Browser's Refresh Button by Default
The server will return a 404 error for sw.js each time we refresh, but the Service Worker thinks that means it should keep...
Read more >
Caching - web.dev
Caching unnecessary resources wastes bandwidth and storage space and could cause your app to serve unintended outdated resources. You don't need to cache...
Read more >
Service worker in production - Angular
Imagine the Angular service worker as a forward cache or a Content ... to serve the old index.html , which calls startApp() ,...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found