Allow waitUntil to be called multiple times, async

[jakearchibald]

waitUntil must be called before returning to the event loop, but it may be called after that if one of its promises hasn't resolved.

respondWith should compose with this, and count as having called waitUntil in the initial turn. As in:

self.onfetch = event => {
  event.respondWith(doSomeThingToGetResponse().then(response => {
    event.waitUntil(doSomeCleanup);
    return response;
  }))
};

[jakearchibald]

+@wanderview :D

[jakearchibald]

F2F resolution: Agreement. Needs specifying.

[mfalken]

Chrome wants to implement this to fix our broken FetchEvent.waitUntil() implementation https://bugs.chromium.org/p/chromium/issues/detail?id=601095. Can we get spec text? Informally, it sounds like:

• FetchEvent.respondWith must be called synchronously in the event handler (at most one time)
• FetchEvent.waitUntil can be called at any time while the worker is alive, and the browser will respect that hint
• The browser tries to keep the worker alive as long as any respondWith or waitUntil promise for the event is pending.

[wanderview]

FetchEvent.waitUntil can be called at any time while the worker is alive, and the browser will respect that hint

I think this should only be allowed if there is already a promise extending the life of the service worker. So you can call waitUntil() asynchronously if you've already called respondWith() or event another waitUntil().

I don't think we should just allow waitUntil() out of the blue without any current promise holding the worker alive because it will lead to racy code in production. Sometimes their waitUntil() will get called in time and sometimes the worker will get killed first.

[jakearchibald]

Here's how I imagined it:

1. ExtendableEvent has an extensions-allowed flag which is set
2. After event dispatch, if extend lifetime promises is empty, unset extensions-allowed & abort these steps
3. Set extend lifetime promises copy to a shallow copy of extend lifetime promises (the promises themselves don't need to be clones)
4. Wait for all promises in extend lifetime promises copy to settle
5. If extend lifetime promises copy's length does not equal extend lifetime promises length, goto 3
6. Unset extensions-allowed

Calling respondWith(promise):

1. If the dispatch flag is unset, throw (as it already does, just want to be clear that respondWith still needs to be called within the dispatch)
2. Add promise to extend lifetime promises

Calling waitUntil(promise):

1. If extensions-allowed is unset, throw
2. Add promise to extend lifetime promises

Sorry for the sloppy prose, but does that make sense?

[wanderview]

Yes. I think that matches what I was thinking.

[mfalken]

Sounds good.

[wanderview]

Gecko bug to implement: https://bugzilla.mozilla.org/show_bug.cgi?id=1263304