No good way to beacon during activate

[asakusuma]

There currently doesn't seem to be a good way to fire a tracking beacon from the activate step. One use case would be tracking how quickly new versions of the service worker are actually activated (vs installed). Current options I can think of for beaconing during activate:

1. waitUntil(fetch('/beaconEndpoint')) This is not good because now all fetch events are temporarily blocked until fetch('/beaconEndpoint') completes.
2. fetch('/beaconEndpoint') (without waitUntil) kicking off async operations outside of waitUntil is not great. Might usually work but seems like it could have unwanted side effects or not be completely reliable, depending on the implementation.

What if we supported sendBeacon for service worker? I believe this would solve the problem.

Another option is to allow some way to schedule a task that doesn't block the event from completing. This would open up a big can of worms though, probably not ideal.

[mfalken]

@yutakahirano

It looks like sendBeacon in workers was removed from the Beacon spec in favor of fetch keepalive:
w3c/beacon#37 (comment)

AFAICT fetch keepalive in workers works in the spec but implementations might not have it implemented yet. E.g., it looks like Chrome cancels the request if the worker is terminated:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/8vqcABTnDF4/xWq1rGGCBwAJ

[asakusuma]

Thanks @mattto! Closing this issue as it looks like keepalive: true solves the problem, at least from a specifications standpoint.

[mfalken]

Let me reopen this because there is some talk of taking this away from service workers:
whatwg/fetch#679

[mfalken]

F2F summary was that there are use cases for fetch keepalive in service workers there's no need for the spec to change the semantics to say it doesn't work in service workers.

cc @yutakahirano