Re: [ServiceWorker] A worker that fails to activate should relinquish its controllees (#659)

> We keep trying to install/activate the same worker each time navigator.serviceWorker.register is called, even if the script hasn't changed.

In the case the registration already has an active worker, `.register()` will return in the step 4.2.2.1 of Register. But when it has a waiting worker/an installing worker, `.register()` will get through to install/activate each time. I agree retaining the registration on error will solve this.

> This makes things difficult for other specs to know when they can fire events such as the push API. 

In the case of fetch, it falls back to network request (we may regard it as the default behavior.) For Push API, there's any expected behavior discussed to date?

> Only .register can trigger a retry.

I suppose we thought that an update for a registration with no worker has no meaning back then. In the case we allow a registration with no worker, I agree this step should be removed.

> If the next worker fails to install, we lose the registration, due to 7.3.3.1 of Install. This means going offline during an update would lose the user's push subscriptions etc.

That scenario is bad, but the current steps have a guard to check whether there was any worker in the registration. So, for instance, if push once successfully subscribed, that associated service worker registration should have an active worker which prevents this registration is deleted when an installation fails.

> Other specs need to deal with queued events losing their associated worker.

Currently, Handle Fetch waits until the activation completes before queuing the task, and in the case it fails it falls back to a network request (the default behavior. See [Handle Fetch](https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#on-fetch-request-algorithm) step 15.)

For other functional events, they are guided to invoke [Handle Functional Event](https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#handle-functional-event-algorithm) which queues a task to call the callbackStep given by those specific APIs. So, one possibility is Handle Functional Event returns some kind of error to the caller when the activation fails so the caller can handle the error with its own default behavior. I'm curious to know what Push and BackgroudSync expect.

/cc @johnmellor @mvano @jkarlin

---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/659#issuecomment-91498522