Process the events reliably with retries

[collimarco]

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 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.

[annevk]

I don't think that really works with the event model as the dispatch caller is not supposed to record exceptions (we have one legacy exception to this rule for Indexed DB, but it should not spread around), and even if one listener did raise an exception, another could still do whatever is needed.

[collimarco]

After further investigation, I have noticed that Background Sync actually supports a retry mechanism: this blog post says that Background Sync can perform retries even when custom exception are raised. Background Sync also waits for the connection to become available before attempting a retry.