Re: [w3c/push-api] Retry push event (#300)

> Please consider thinking about an upgrade path

In theory I can agree, but in practice we cannot change a core feature like this. Any small problem may have disrupting consequences on our business. It is very likely to encounter problems: for example on many browsers versions it is difficult to update the service worker code imported with importScripts.
In any case I don't think that my specific case is relevant: I think that this discussion must be valid in  general. 

**In general it is valid to receive a `push` signal without payload and in general 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/push-api/issues/300#issuecomment-418537037