fix: SW reload bypasses old runtime HTML cache on post-update reload - #458
Merged
Conversation
SW no longer calls skipWaiting + clients.claim directly. Instead it sends a RELOAD_APP message to the app, which calls location.reload with a __sw_reload=<timestamp> query param. The OLD SW's navigation handler detects the param, bypasses its own runtime-html cache, and fetches fresh HTML from the network. The new SW then caches the fresh HTML in its own bucket on subsequent navigations. Why this matters: skipWaiting + clients.claim() triggers an automatic reload controlled by the OLD SW's fetch handler, which serves from the old runtime-html cache first (stale-while-revalidate). The stale HTML boots the old app bundle, CHECK_VERSION sees matching versions, no further reload fires, and the update banner persists until the user fully kills the app.
ciotlosm
force-pushed
the
fix/version-check-ticker-and-sw
branch
from
July 22, 2026 21:04
46ef5f0 to
332fe4b
Compare
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
1 participant
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
The update banner sometimes persists until a full app kill because the SW
reload path serves stale HTML from the OLD SW's runtime HTML cache.
Root cause
When a new version drops, the old sequence was:
skipWaiting()+clients.claim()runtime-html-vOLD-v1cache firstversions → no further reload → banner persists
Fix
SW no longer calls
skipWaiting+clients.claim()directly. Instead it sendsa
RELOAD_APPmessage to the app with a timestamp. The app callslocation.reload('?__sw_reload=<timestamp>'). The OLD SW's navigationhandler detects the param, bypasses its own runtime HTML cache, and fetches
fresh HTML from the network. The new SW then caches the fresh HTML in its
own bucket on subsequent navigations.
The
?__sw_reloadparam is stripped before storing, so subsequentnavigations hit the normal stale-while-revalidate path.
Offline safety: if the network is down on the post-update reload, the
handler falls back to the precache (always has
/index.htmlfrom install).