Possible race between Activate and Update Algorithms

[catalinb]

Consider the case of a service worker which always fails the byte check comparison because the web server generates the script dynamically and calls registration.update() in the activate event handler.

 // some unique random string dynamically generated by the web server
 onactivate = function(e) {
 e.waitUntil(self.registration.update());
}

In step 12 of the activate algorithm we need to wait for all waitUntil promises to resolve/reject before
invoking Update Worker State passing activated as an argument. self.registration.update() is resolved as a result of a job queued in step 6 of the install algorithm.
At this point, the registration has an installing worker and a waiting worker. Now, if the install algorithm reaches step 15.1 and terminates the waiting worker before the promise is resolved, it will never reach "activated" state (step 13 Activate Algorithm).

This is currently observable in Firefox, listening for worker state changes when registering this script, will reach either "activating" or "activated".

[mfalken]

At this point, the registration has an installing worker and a waiting worker.

Hm, wouldn't it be an installing worker and active worker? Once you're in onactivate, you're the active worker. The active worker should be protected from being terminated while the waitUntil() promise is open via Try Activate's "Service Worker Has No Pending Events" check. If the waiting worker called skipWaiting(), the site has opted into the race anyway.

[wanderview]

@catalinb What firefox bug is this? Do we have a reduced test case?

Depending on what the test is doing there may be additional updates running due to navigation, etc. Those are fired from timers and might be confusing things.

Its also possible that when the activating worker goes idle we process the pending update before firing the state change event to the final "activated" state. I think we should be waiting for the event to complete, though.