fix(pwa): stop precaching the shell and bundles so deploys do not strand open tabs - #8
Merged
Merged
Conversation
…and open tabs The service worker precached index.html and every hashed chunk. Opening the app at / was served the previous build's shell from the precache, and when the new worker activated it deleted the old chunks, so those stale tabs 404'd on the next lazy route. The shell now always comes from the network and /assets/* is runtime-cached (CacheFirst, 30d) so a tab keeps its own build's chunks across deploys; sw.js no longer changes per deploy.
Author
|
I'll fix CI failures and address comments from users with write access. I'll skip comments containing "(aside)".
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Admins hit
Failed to fetch dynamically imported module: /assets/ReviewsPage-<hash>.js(the router's 500 page) after deploys. The chunk 404 itself is inherent to hashed bundles + a fresh Cloud Run image, but the service worker was manufacturing the stale pages that request them:sw.tsusedprecacheAndRouteover**/*.{js,css,html,...}. Workbox serves/from the precachedindex.htmlcache-first, so opening the app (PWA start_url / bookmark) after a deploy loaded the previous build's shell with zero network requests — reproduced locally in Chrome.skipWaiting()s, claims the open tabs, and Workbox's precache cleanup deletes every old chunk. Any tab still running the old build 404s on its next un-visited lazy route./sw.jswithcache-control: max-age=3600, cf-cache-status: REVALIDATEDeven thoughspa.gosendsno-cache, so the SW update itself lags up to an hour after a deploy, extending the stale window. Needs a Cache Rule bypassing/sw.jsand/registerSW.js.)Change:
Effects, verified with a local two-build "deploy" simulation against Chrome:
/is always fetched from the network (no-cachefromspa.go), so every open gets the current build's shell.harp-assets(probed withfetch(..., {cache: "no-store"})→ 200 with no origin request) instead of 404ing; only chunks it never loaded before the deploy still 404, and those are handled by the existingvite:preloadErrorauto-reload.sw.jsno longer changes per deploy (byte-identical across the two builds), so the skipWaiting/claim/cleanup rug-pull stops happening on every merge, and users stop re-downloading a ~7 MB precache each deploy.Not changed: the transition from the current precaching worker to this one behaves like one last deploy (old precached chunks are cleaned up once); push handlers are untouched.
Link to Devin session: https://app.devin.ai/sessions/00c881e94b064b5780794038f0f4813e
Open in Devin Desktop: https://app.devin.ai/desktop/session/00c881e94b064b5780794038f0f4813e?variant=devin
Requested by: @balebbae