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

To start with the obvious: critical data associated with a push message, like the notification that should be shown, should be included as its payload. The ~4KB limit prescribed by RFC8030 should hopefully be sufficient for that. To my knowledge, all current implementations will gracefully handle subsequent fetch failures and timeouts caused by resources included in `showNotification`.

The main two use-cases for additional fetches that I'm aware of are:

1. Prefetching content that should be available offline when the notifications is activated. I think [Background Sync](https://wicg.github.io/BackgroundSync/spec/) would be a better venue for that, because it already provides the necessary reliability.
1. Analytics pings. While important for developers, a retry mechanism could end up being very expensive for users—particularly those on low-end devices.

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

Putting my Chrome hat on and looking at our metrics, just over 1% of `push` events result in `waitUntil()` being rejected. While that may seem low, it raises a compatibility concern if any notifications were shown already, as they would be shown again.

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