Recovering from start failures

[ytausky]

Currently when a service worker fails to start, the result is a network error. A service worker failing to start can happen due to a bad script or other non-transient errors, so it would be more useful for the user to have a fallback that bypasses the service worker in this case.

[bzbarsky]

If I understand correctly, the fallback behavior is in fact what Chrome implements, and this is causing compat problems because some sites are relying on it. @wanderview @foolip

[wanderview]

Can you define what you mean by "bad script"? The installation should not allow a bad script to be persisted. Are we discussing storage corruption or other browser internal error?

In any case, I think we should not break the site in these cases. I think failing safe by falling back should be preferred since there is nothing the site can do to fix the issue.

So I would be in favor of changing step 23 here:

https://w3c.github.io/ServiceWorker/#on-fetch-request-algorithm

[ytausky]

By "bad script" I mean one that has an error on a subsequent evaluation and thus cannot be started. For example, by using the current time as part of the URL of an imported script it's possible to create a worker script that evaluates correctly the first time, but fails on a subsequent run (because it tries to import a new script).

[wanderview]

Hmm, a programming error like that does seem like it should fail the request. But I still feel other internal causes of the SW failing to start should fallback. Although I would be happy if they all fell back if that is easier.

@mattto @jakearchibald what do you think?

[mfalken]

https://w3c.github.io/ServiceWorker/#run-service-worker-algorithm returns failure or the Completion returned from https://html.spec.whatwg.org/multipage/webappapis.html#run-a-classic-script.

If a runtime error occurs, it returns a Completion containing the error (an "abrupt completion").

If the script couldn't run due to an internal error (the browser couldn't run the worker to completion), it returns failure.

Currently the spec says that failure results in a network error, but on an uncaught runtime error the service worker is considered running and it dispatches the fetch event as usual.

Only the Update algorithm cares about runtime errors at step 18:

17. Let runResult be the result of running the Run Service Worker algorithm with worker and forceBypassCache.
18. If runResult is failure or an abrupt completion, then:
    18.1 Invoke Reject Job Promise with job and TypeError.

Chrome is doing fallback in both cases, whereas the spec says only do it on runtime error. I agree the behavior is a bit magical. The fallback was done as a safeguard.

We should also consider the case like when the user disables JS. In this case, I believe Run Service Worker will return failure. We probably want to "fallback" in this case though.