Investigate the cache issue #62
Comments
|
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 |
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
After each deployment, the site is broken during some minutes / hours. Probably because of cache issue related to service workers.
The text was updated successfully, but these errors were encountered: