Expose more events from service worker update cycle

[marcinowski]

🚀 feature request

Relevant Package

This feature request is for @angular/service-worker

Description

We are currently experiencing an issue with a significant percentage of our users using outdated versions of our application. We're not really sure whether they're taking a very long time to update their applications or is it more of a problem with detection of the new version or something else. We don't have enough data to determine whether there is an issue with our service worker implementation, an issue with our application or maybe some edge case in the framework. Currently the service worker exposes only the available and activated events. This gives only a bit of an insight on how does the service worker perform updates on the client side.

Describe the solution you'd like

As mentioned before the service worker currently exposes only two events

• a new version is available to be activated
• a new version has been activated

Ideally the service would expose some additional events like

• a new version has been detected to exist (but is not available to use yet)
• a new version starts downloading
• a new version finishes downloading

This would allow us to track those events, figure out why is it that some users are taking very long time to get the new version and/or maybe optimise some parts of the flow.

EDIT(gkalpak)
Related issue: #34397

[gkalpak]

This sounds reasonable. The current update notification workflow is indeed less than ideal.

FWIW, you can have a little more control by calling SwUpdate#checkForUpdate() explicitly (instead of relying on the SW to check for updates automatically). While checkForUpdate() does not report whether an update was found or not (this is another area we can improve) it allows you to know when a check happened.

Then by subscribing to SwUpdate#available you can know whether a new version has been detected. If a new version is detected, it will be downloaded and emitted on SwUpdate#available before the promise returned by checkForUpdate() resolves. So, that could be used to emulate your "a new version finishes downloading" event.

If the promise returned by checkForUpdate() resolves without a value being emitted on SwUpdate#available, this can mean two things:

1. There is no update available.
2. There was an error while checking or downloading the update.

There is no straight-forward way to distinguish the two, but if an error occurred the SW would have entered a degraded mode. So, you can determine what happened by requesting ngsw/state parsing it manually for the SW state with somthing like:

fetch('ngsw/state').
  then(res => res.text()).
  then(res => /Driver state: (\w+)/.exec(res)[1])

You can read more about the available debug options here.

---

I am going to leave it open as a feature request, but it is not a high priority. If anyone wants to take it on, I would be happy to help/review.

[marcinowski]

Thanks for a very helpful comment @gkalpak. What you're saying makes a lot of sense and it's definitely something that we're going to try. I'm also glad you find the feature request reasonable, I'll try to find some time and produce a PR

[TheParad0X]

Hello,

I was asked to post my ideas here :)

This feature request is for @angular/service-worker

The current API is not very user-friendly. So far, in order to check for updates, I have to do the following:

• Call checkForUpdate() every N minutes. When it returns, I don't know if the check was successful and if there is an update
• I have to subscribe to SwUpdate.available(), and I can act accordingly, for example prompt the user
• SwUpdate.available() seems to fire only once, I need to save (or remember) that an UpdateAvailableEvent is available (if the user clicks "No" in my "Would-you-like-to-reload-prompt". Also, SwUpdate.available() seems to be firing twice in a row from time to time, I have not been able to reproduce it consistently.
• SwUpdate.activateUpdate() also does not give my anything useful in return.
• Finally, I am having problems updating my Service Worker on an Android tablet where my PWA has been "installed", whereas it works when running in a browser (still on the tablet)

How I would like the API to be:

• checkForUpdate() returns Observable if there is an update, or undefined if not. And an error if the check failed (no connection?)
• activateUpdate() returns Observable with true if it was successful, or false if not

Does this make sense?

Cheers

[angular-robot]

Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.

Find more details about Angular's feature request process in our documentation.

[angular-robot]

Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.

We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.

You can find more details about the feature request process in our documentation.

[spike-rabbit]

@gkalpak Is it possible to provide a PR although the Issue got insufficient votes?
I am interested in a new version has been detected to exist (but is not available to use yet) event, but I can do some of the other stuff as well.

If your answer is yes, do you have a suggestion for the API or should I provide an Idea?

[gkalpak]

While this got insufficient votes, I do believe it is a useful addition (esp. since the current implementation is a little unintuitive).
We'll discuss this with the team and decide if there is still merit in moving it forward (although I don't have a timeline - there are dozens of issues to go through 😅).

I don't have any concrete API suggestions, but feel free to go ahead a make one (and provide a PR) 😉

[spike-rabbit]

Sorry for my long response time. Here is my suggestion for the API modifications:

I would add a new field to NgUpdate:

potentialUpdateAvailalbe: Observable<PotentialUpdateAvailableEvent> .

This should meet the a new version has been detected to exist (but is not available to use yet) and a new version starts downloading event. At least for me it looks there is no need to differentiate as downloading starts immediately after the potential update was detected.

Same is for a new version finishes downloading which is basically the same as a new version is available to be activated.

Regarding @TheParad0X comment:

I guess sticking to Promises is fine here as Observables would require a call to .subscribe(). But I can agree on adding a meaningful return value. I would prefer a signature like this:
checkForUpdate(): Promise<UpdateAvailableEvent | NoUpdateAvailableEvent | UpdateFailedEvent>. Throwing an error in case of failure would force applications to catch it which would be definitely a breaking change.

And for activateUpdate it could look like this: activateUpdate(): Promise<UpdateActivatedEvent | ActivationFailedEvent>.

TBH I am not sure if returning the events is the best way here. If an error is thrown in case of failure, returning a boolean value would be possible as well.

@gkalpak WDYT?

[gkalpak]

Thx for putting this together, @spike-rabbit.

I took some time to (briefly) think about the API today, so here are my thoughts.

First of all, as a point of reference, here is what the SwUpdate public API looks like today:

class SwUpdate {
  available: Observable<UpdateAvailableEvent>;
  activated: Observable<UpdateActivatedEvent>;
  unrecoverable: Observable<UnrecoverableStateEvent>;
  isEnabled: boolean;
  checkForUpdate(): Promise<void>;
  activateUpdate(): Promise<void>;
}

NOTE:
One limitation of the mechanism currently used under the hood to communicate between the Angular SW and the app is that it only reports whether an operation has been completed, without a way to convey the result of the operation (such as whether checking for an update yielded an update or not).
I think we should enhance that mechanism to be able to report richer information about an operation.

Trying to stay as backwards compatible as possible, I might propose the following changes to the SwUpdate public API (off the top of my head - this is not really thought through). These are similar to your suggestions, @spike-rabbit, just a little more concrete (and a little more backwards compatible).

• Keep isEnabled and unrecoverable as is.
• Update checkForUpdate() to return a promise resolving to true/false on successful completion (indicating whether an update was found (and successfully downloaded) or not) and rejecting on failure.
  I.e. resolving to true means an update was found and downloaded and is ready to use, resolving to false means no update was found and rejecting means an error happened while either checking for an update or downloading it.
• Update activateUpdate() to return a promise resolving to true/false on successful completion (indicating whether an update was activated or not (because the client was already on the latest version)) and rejecting on failure.
• Introduce a new versionUpdates observable (name TBD 😁) that emits the following types of events:
  • VersionDetectedEvent (implies that a new version is detected on the server and is being downloaded):

    {
      type: 'VERSION_DETECTED';
      version: {
        hash: string;
        appData?: object;
      };
    }

  • VersionInstallationFailedEvent (implies that there was an error preparing the version (i.e. downloading or updating local SW state)):

    {
      type: 'VERSION_INSTALLATION_FAILED';
      version: {
        hash: string;
        appData?: object;
      };
      error: string;
    }

  • VersionReadyEvent (implies that a new version has been installed and is ready to be activated for the client):

    {
      type: 'VERSION_READY';
      currentVersion: {
        hash: string;
        appData?: object;
      };
      latestVersion: {
        hash: string;
        appData?: object;
      };
    }

  Not a big fan of the name, but VersionAvailableEvent sounded confusingly similar to VersionDetectedEvent (i.e. people might easily interpret it as "a new version is available on the server") and VersionInstalledEvent could be easily interpreted as "the version has been activated and is in effect for this client").

• Consider deprecating (and eventually removing) the available observable, since it could now be constructed from versionUpdates. For example:

  available = swUpdate.versionUpdates.pipe(
    filter(evt => evt.type === 'VERSION_READY'),
    map(evt => ({
      type: 'UPDATE_AVAILABLE',
      current: evt.currentVersion,
      available: evt.latestVersion,
    })),
  );

• Consider deprecating (and eventually removing) the activated observable, since (in practice) it only really emits in response to calling activateUpdate().

With that, the SwUpdate public API surface would look like:

class SwUpdate {
  /** @deprecated */
  available: Observable<UpdateAvailableEvent>;
  /** @deprecated */
  activated: Observable<UpdateActivatedEvent>;
  versionUpdates: Observable<VersionDetectedEvent | VersionInstallationFailedEvent | VersionReadyEvent>;
  unrecoverable: Observable<UnrecoverableStateEvent>;
  isEnabled: boolean;
  checkForUpdate(): Promise<boolean>;
  activateUpdate(): Promise<boolean>;
}

WDYT, @spike-rabbit, @marcinowski, others?

[spike-rabbit]

Thx a lot @gkalpak. Your proposal would perfectly fit our needs. UnfortunateIy I cannot either come up with better names for the new Observables and it's events.

Unless you will implement this, I could provide a PR in the second half of september.

[gkalpak]

I certainly won't get to it any time soon, so feel free to submit a PR 😉
I'll be happy to review and help with questions.

[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.}