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

> Are you thinking about one of those cases, or another case?

I am talking about another case: **we receive a *push event without payload* and then we download the pending notifications from the *application server*.** This was the only method available in 2015 when we started developing Pushpad.xyz and I think that many other services do the same: now in our database we have millions of subscriptions that have an endpoint but not the keys to encrypt a payload (because we don't use that). This method is the original method suggested by the Push API, it is compatible with all the current browsers and works well: so I hope you won't break this in the future. Please also see / accept this related request: https://github.com/w3c/push-api/issues/289 Finally I would like to mention that this method doesn't increase the bandwidth usage since we would have to send a request to the server in any case to track the delivery.

> all current implementations will gracefully handle subsequent fetch failures and timeouts caused by resources included in showNotification

For the above reasons I think that it would be useful to **apply that retry mechanism** not only to the showNotification resources (like icon), but **to the entire `push` event**, so that a `fetch` that raises an exception will cause the entire `push` event to be retried (e.g. with exponential backoff).

If you don't want to retry the push event by default (which imho is the best option) you could at least provide an `event.retryUntil` that allows you to run some code reliably with retries.

> they would be shown again

I think that it is much better to show the notification twice than loosing a notification. Also I think that it is a common practice to retry failed jobs (e.g. server side you always do that). Finally **you can use the [Notification `tag`](https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerRegistration/showNotification#Parameters) to avoid duplicates: so I don't see any drawback**.

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