ServiceWorker doesn't always trigger .available method

[hassanasad]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[X] Bug report  
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
[ ] Other... Please describe:

Current behavior

The service worker doesn't always trigger .available() method after when it downloads new files in the background. Sometimes it does and sometimes it doesn't and is rather random.
Here is my code that checks for updates every 2.5 mins.

File app.component.ts

	private setupServiceWorker(): void {
		if ( this.swUpdate.isEnabled && environment.allowServiceWorker ) {
			// Check for update
			this.appUpdateIntervalSub = interval( 1000 * 60 * 2.5 ).subscribe( () => {
				this.swUpdate.checkForUpdate();
			} );

			// New app version is available
			this.appUpdateAvailableSub = this.swUpdate.available.subscribe( () => {
				console.log('SW Available');
				// New version of app is available - notify user to refresh browser
				this.showAppUpdateMessage = true;
			});
		}
	}

I do not get the console.log('SW Available') messages everytime.

Route data of /ngsw/state:

NGSW Debug Info:

Driver state: EXISTING_CLIENTS_ONLY (Degraded due to failed initialization: Hash mismatch (cacheBustedFetchFromNetwork): https://myDomainName/index.html: expected c4f0a150ff312ec887e7be08af365d271fd9f06c, got bfe58f87b8ea9c0cd8adae7224ebb955cdece43e (after cache busting)
Error: Hash mismatch (cacheBustedFetchFromNetwork): https://myDomainName/index.html: expected c4f0a150ff312ec887e7be08af365d271fd9f06c, got bfe58f87b8ea9c0cd8adae7224ebb955cdece43e (after cache busting)
    at PrefetchAssetGroup.<anonymous> (https://myDomainName/ngsw-worker.js:670:31)
    at Generator.next (<anonymous>)
    at fulfilled (https://myDomainName/ngsw-worker.js:304:58))
Latest manifest hash: d88b815671b5211492c12506ee12732d482d6dab
Last update check: 2m2s134u

=== Version 1d60db65d5801d39103c347b22b9b583b2c1a31d ===

Clients: 

=== Version d88b815671b5211492c12506ee12732d482d6dab ===

Clients: 

=== Idle Task Queue ===
Last update tick: 2m7s567u
Last update run: 2m2s566u
Task queue:


Debug log:

[36m42s792u] Ignoring invalid request: 'only-if-cached' can be set only with 'same-origin' mode Driver.fetch(https://myDomainName/, cache: only-if-cached, mode: no-cors)
[34m40s732u] Error(Hash mismatch (cacheBustedFetchFromNetwork): https://myDomainName/index.html: expected c4f0a150ff312ec887e7be08af365d271fd9f06c, got bfe58f87b8ea9c0cd8adae7224ebb955cdece43e (after cache busting), Error: Hash mismatch (cacheBustedFetchFromNetwork): https://myDomainName/index.html: expected c4f0a150ff312ec887e7be08af365d271fd9f06c, got bfe58f87b8ea9c0cd8adae7224ebb955cdece43e (after cache busting)
    at PrefetchAssetGroup.<anonymous> (https://myDomainName/ngsw-worker.js:670:31)
    at Generator.next (<anonymous>)
    at fulfilled (https://myDomainName/ngsw-worker.js:304:58)) initializeFully for 1bab97af18ccaca1f545df20278dd011cd0ce7d1

Expected behavior

It should trigger .available() method of ServiceWorker update class each time a new version is of the app is downloaded in background.

Minimal reproduction of the problem with instructions

Its a bug that appears randomly so cannot give Reproduction steps

What is the motivation / use case for changing the behavior?

The users cannot be notified that a new app version has been released and so refresh the browsers.

Environment

Angular CLI: 6.0.8
Node: 10.1.0
OS: darwin x64
Angular: 6.0.7
... common, compiler, compiler-cli, core, forms, http
... language-service, platform-browser, platform-browser-dynamic
... router, service-worker

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.6.8
@angular-devkit/build-angular     0.6.8
@angular-devkit/build-optimizer   0.6.8
@angular-devkit/core              0.6.8
@angular-devkit/schematics        0.6.8
@angular/cli                      6.0.8
@ngtools/webpack                  6.0.8
@schematics/angular               0.6.8
@schematics/update                0.6.8
rxjs                              6.2.1
typescript                        2.7.2
webpack                           4.8.3

Browser:
- [ X ] Chrome (desktop) version 67
 
For Tooling issues:
- Node version: 10.1.0
- Platform:  Mac

Others:

[hassanasad]

@gkalpak Perhaps something you might be interested in ;)

[gkalpak]

I would be interested, except...

According to /ngsw/state the SW is in "safe mode" (EXISTING_CLIENTS_ONLY). Which means that something is wrong with the manifest. It's no wonder it doesn't advertize is as "available update" 😃

You need to make sure there is no issue with the manifest and (if then the problem persists) open a new issue providing the necessary details to reproduce the problem.

_{I am going to close this, since everything seems to work as expected. But happy to investigate the issue if you can provide more details.}

[hassanasad]

@gkalpak Are you referring to manifest.json file ?

If you are this is the content:

{
  "name": "MyApp",
  "short_name": "MyApp",
  "theme_color": "#FF5000",
  "background_color": "#fafafa",
  "display": "standalone",
  "scope": "/",
  "start_url": "/",
  "icons": [
  ]
}

[gkalpak]

No, sorry I wasn't more clear. I was referring to the generated ngsw.json file. It contains (among other things) hashes for the files that need to be cached by the SW. The hash for https://myDomainName/index.html does not match the content of the served index.html file, which causes the SW to enter "safe mode".

This is probably because you alter the contents for the file after ngsw.json has been generated.

[hassanasad]

Actually didn't alter anything after the build was generated. When we used to do that (as per my previous issue) it would loose file integrity and download that same file every time it was checking for new version.
Now we are just uploading all the files from dist folder directly onto S3 without file alterations.

[hassanasad]

Sometimes while the files are being uploaded to S3 bucket, i am assuming browsers are still requesting ngsw.json for new versions and they will get 404 and then they will resume the checks once the upload is completed - can that lead to that manifest issue you mentioned ?

[gkalpak]

In any case, there is a hash mismatch (which means different content between building the app and serving the app) as mentioned in the SW logs:

Degraded due to failed initialization: Hash mismatch [...]: https://myDomainName/index.html:
expected c4f0a150ff312ec887e7be08af365d271fd9f06c,
got bfe58f87b8ea9c0cd8adae7224ebb955cdece43e

[gkalpak]

Yes, I guess if S3 serves ngsw.json from one deployment and index.html from another deployment (as you described), that could explain the issue. But it shouldn't happen often and should get fixed on next reload or check for update.

[hassanasad]

It could happen because its possible ngsw.json gets uploaded first and the worker file processes it trying to fetch files that are not uploaded completely. However i would assume on next check if file integrity is matching again - it should trigger .available method since SW did download new files.

[tobo37]

I had the same Problem. For me the solution was to modify the ngsw-config.json. I found in the Angular documentation (https://angular.io/guide/service-worker-config#appdata)

"appData
This section enables you to pass any data you want that describes this particular version of the app. The SwUpdate service includes that data in the update notifications."

so I add "appData": [ "/index.html", "/*.css", "/*.js" ],

By default the SwUpdate checkts only the index.html.

I hope it will help you.

[gkalpak]

@tobo37, I'm afraid appData is totally irrelevant here. It does not cause the SW to check anything 😕

[angular-automatic-lock-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.}