[w3c/ServiceWorker] Process the events reliably with retries (#1352)

Currently Service Workers don't offer a way to process an event reliably - i.e. make it resistant to network errors or other temporary exceptions (e.g. HTTP 503).

Some APIs built on top of Service Workers, like the Push API trigger one-off events that should not be lost in case of temporary exceptions. Examples include `push` and `pushsubscriptionchange`.

This technology would become much more reliable if it could **offer a way to retry an event until it gets executed successfully**. Most server-side "workers" can retry a job with exponential backoff if it raises an exception: it would be useful to have a similar functionality on the client-side.

[My proposal started here](https://github.com/w3c/push-api/issues/300#issuecomment-418537037) for the Push API, but then I realized that it may have more general implications.

> [...] many developers may want to process that event reliably - i.e. have a way to retry the event if a temporary exception occurs.
>
> Currently Javascript Events, Service Workers and the Push API don't offer a way to process an event / some code reliably. The only similar solution is the **Background Sync**, however it is not an actual solution for the following reasons:
> - **it manages only internet problems and not other exceptions** (e.g. think about an exception raised because you receive a 503 from the application server)
> - **the sync event offers a context with different capabilities compared to the original event**; for example you can display a notification inside the push event, but you cannot do that inside the sync event (probably won't work); the point is that what we actually need is a way to re-dispatch the exact same event with the same context and same capabilities
>
> I think that the event should offer a method like `event.retryUntil(<Promise>)` which ensures that multiple retries will be performed if the promise fails. A method like this would be useful for many events of the Push API (e.g. push, pushsubscriptionchange). I think that this method can be actually implemented in browsers:
> 1. The browser saves the event type (e.g. push) and the event object locally in a file; no additional data or code must be saved
> 2. The browser triggers the event again when it can do that - it can be after a few milliseconds or, if the browser process gets killed by the OS in the meantime, it can be many hours later when the user opens the browser again
> 3. On success, or after N failed attempts the browser aborts this steps
>
> The above solution would be also "Web compatible" / backward compatible. Also I don't see any system constraints for a solution like this.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1352