Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate the cache issue #62

Open
dunglas opened this issue Jul 20, 2018 · 1 comment
Open

Investigate the cache issue #62

dunglas opened this issue Jul 20, 2018 · 1 comment

Comments

@dunglas
Copy link
Member

dunglas commented Jul 20, 2018

After each deployment, the site is broken during some minutes / hours. Probably because of cache issue related to service workers.

@Fabious
Copy link
Contributor

Fabious commented Sep 7, 2018

We got exactly this bug : gatsbyjs/gatsby#4636

It's most certainly come from the gatsby-plugin-offline

Apparently it's only happens Chrome (need testing)

Hard to test locally
possible fix ?

manuelkiessling added a commit to manuelkiessling/nodebeginner.org that referenced this issue Sep 17, 2018
…blem.

The problem was as follows:

- Webpack builds the app js and stores it as e.g. app.hash-1.js
- When requesting the server, the client initializes the service worker,
  which in turn stores /sw-precache-appshell in the cache; in
  sw-precache-appshell's HTML, app.hash-1.js is referenced; also
  app.hash-1.js is stored in the cache
- On subsequent soft-loads, the content of sw-precache-appshell is
  served from the cache
- The app is changed and rebuilt, resulting in file app.hash-2.js; file
  app.hash-1.js is no longer served by the backend
- Another soft-load results in the cached version of
  sw-precache-appshell being served, which still references
  app.hash-1.js - as this is still in the cache and served from there,
  all works fine
- The service worker fetches itself at /service-worker.js, realizes that
  the app js has changed, fetches app.hash-2.js, and stores that in the
  cache, removing app.hash-1.js from the cache; however, the service
  worker does not realize that /sw-precache-appshell changes, which
  could be a bug in sw-prefetch; thus the "old" version of
  sw-precache-appshell which still refers to the "old" app.hash-1.js,
  remains in the cache
- Doing a soft-load again, the service worker serves the old
  sw-precache-appshell content, where app.hash-1.js is now referenced;
  as this is available neither from cache nor from the backend, the app
  stops working

The solution here is to NOT use any kind of hash-based file naming for
WebPack-generated files, but simply use a static name; this way, the
reference is always to "app.js" which always matches, while the service-
worker still knows when to fetch new file content and update the cache.

See GoogleChromeLabs/sw-precache#356
See api-platform/website#62
See gatsbyjs/gatsby#4636
See GoogleChromeLabs/sw-precache#269 (comment)
manuelkiessling added a commit to manuelkiessling/nodebeginner.org that referenced this issue Sep 17, 2018
…blem.

The problem was as follows:

- Webpack builds the app js and stores it as e.g. app.hash-1.js
- When requesting the server, the client initializes the service worker,
  which in turn stores /sw-precache-appshell in the cache; in
  sw-precache-appshell's HTML, app.hash-1.js is referenced; also
  app.hash-1.js is stored in the cache
- On subsequent soft-loads, the content of sw-precache-appshell is
  served from the cache
- The app is changed and rebuilt, resulting in file app.hash-2.js; file
  app.hash-1.js is no longer served by the backend
- Another soft-load results in the cached version of
  sw-precache-appshell being served, which still references
  app.hash-1.js - as this is still in the cache and served from there,
  all works fine
- The service worker fetches itself at /service-worker.js, realizes that
  the app js has changed, fetches app.hash-2.js, and stores that in the
  cache, removing app.hash-1.js from the cache; however, the service
  worker does not realize that /sw-precache-appshell changes, which
  could be a bug in sw-prefetch; thus the "old" version of
  sw-precache-appshell which still refers to the "old" app.hash-1.js,
  remains in the cache
- Doing a soft-load again, the service worker serves the old
  sw-precache-appshell content, where app.hash-1.js is now referenced;
  as this is available neither from cache nor from the backend, the app
  stops working

The solution here is to NOT use any kind of hash-based file naming for
WebPack-generated files, but simply use a static name; this way, the
reference is always to "app.js" which always matches, while the service-
worker still knows when to fetch new file content and update the cache.

See GoogleChromeLabs/sw-precache#356
See api-platform/website#62
See gatsbyjs/gatsby#4636
See GoogleChromeLabs/sw-precache#269 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants