Service worker returning outdated index.html

🐞 bug report

Affected Package

The issue is caused by package @angular/service-worker

Description

I have a problem with the Angular service worker returning an old version of index.html (from the date the service worker was installed) that is driving me bonkers!

Basically on a fresh startup of the browser (chrome) the old index.html is being served by the service worker resulting in a defunct mainxxx.js being loaded and due to the IIS rewrite rule I have in play to support deep linking, mainxxx.js returns back with the contents of index.html (side effect of service worker returning wrong index.html in first place)

When I soft or hard refresh the browser tab, the correct index.html is loaded and all is fine… that is, until I close the browser and start again at which point the old index.html is served up again 😮

I am a side-by-side deployment strategy, which basically means that a new folder is created every time ther eis a new deploy and the web hosting is then pointed at this new folder, thus the old files are not available while hosting the new deploy!

As you can see from the screenshot below (sorry about the redaction), I have turned off caching via the cache-control header for the index.html page and other service worker related files…

The below is a copy of my ngsw-config.json { "index": "/index.html", "assetGroups": [{ "name": "app", "installMode": "prefetch", "resources": { "files": [ "/favicon.ico", "/index.html", "/*.css", "/*.js" ] } }, { "name": "assets", "installMode": "lazy", "updateMode": "prefetch", "resources": { "files": [ "/assets/**" ] } }] }

🔬 Minimal Reproduction

Not sure how I can easily replicate as it requires publishing a few different versions etc!

🌍 Your Environment

Angular Version:

Angular CLI: 7.0.6
Node: 10.10.0
OS: darwin x64
Angular: 7.1.0
... animations, common, compiler, compiler-cli, core, forms

Package                             Version
-------------------------------------------------------------
@angular-devkit/architect           0.10.6
@angular-devkit/build-angular       0.10.6
@angular-devkit/build-optimizer     0.10.6
@angular-devkit/build-webpack       0.10.6
@angular-devkit/core                7.0.6
@angular-devkit/schematics          7.0.6
@angular/cli                        7.0.6
@angular/http                       7.1.3
@angular/language-service           7.1.3
@angular/platform-browser           7.1.3
@angular/platform-browser-dynamic   7.1.3
@angular/pwa                        0.8.8
@angular/router                     7.1.3
@angular/service-worker             7.1.3
@ngtools/webpack                    7.0.6
@schematics/angular                 0.8.8
@schematics/update                  0.10.6
rxjs                                6.3.3
typescript                          3.1.6
webpack                             4.19.1

Anything else relevant? I’ve only testing in chrome so far.

• I’ve tried with an incognito tab mode where everything works as required
• Clearing down the service work cache works… but not suitable for end users
• uninstalling the service worker works… but not suitable for end users

It’s also been suggested via my overflow question that having the dev tools (inspector) window open could be causing the issue, though this is happening in production where the user does not have the dev tools open!

[gkalpak]

There doesn’t seem to be anything unexpected there. Basically, the SW is correctly entering a degraded (EXISTING_CLIENTS_ONLY) state (since it is getting a 200 request for a hashed file but with different than expected content). What this means is that:

1. Other clients (e.g. opening a second tab or reloading the current tab) should not be handled by the SW (but passed through to the network).
2. The latest manifest should be fetched, so clients would be served by that in the future.

But that is what should happen theoretically 😁 The actual behavior might defer (e.g. due to a bug).

Feel free to send more info to my e-mail.

BTW, I would highly recommend not serving index.html for requests to files (e.g. URLs whose last path segment contains a dot (.)), because that can cause all sorts of funny issues (with and without SW).

[angular-automatic-lock-bot[bot]]

This issue has been automatically locked due to inactivity. Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}