Re: [ServiceWorker] Event queuing model for SW (#649)

Struggling to get a handle on this, so here's some use cases:

The browser has 100 fetch events queued, but the user navigates or hits "stop". Firing those 100 events would be wasteful, ideally the browser should be able to take them out of the queue. The SW may not be able to terminate, as the navigated-to page may also need the SW.

The browser has 100 fetch events queued, but the user closes the browser. Firing those 100 events is probably not possible, but they shouldn't be fired next time the browser opens - the reopening of the page will refire them.

The browser has fetches & push events queued while the activate event for the target ServiceWorker is underway. However the activation fails leaving the registration without an active worker. I guess the queue should remain at this point? Added this concern to https://github.com/slightlyoff/ServiceWorker/issues/659#issuecomment-87778808 - worried about a large buildup of events here.

The browser has 10 fetch events queued, 3 fired and awaiting response, and an additional push event with an unsettled waitUntil. The ServiceWorker crashes for reasons unknown. I think the three fetch events & push should be treated as if they were given a rejected promise. The SerivceWorker should restart and the queue should continue to process (the previously fired events are not rescheduled unless they typically do when their waitUntil/respondWith promise rejects, as is the case with one-off background sync).

Does that help any?

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