-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Retry push event #300
Comments
There are two network errors you are talking about here:
|
I am talking about point 2. The application server can be temporary inaccessible due to maintenance or due to internet connection problems that are not caused by the application server itself - e.g. the user device looses the internet connection after receiving the
In that case the application server has received a (*) Actually it makes sense to not perform retries: you have received a IMHO The Push API / service workers should provide a way to process the event in a reliable way. |
Two other considerations:
Does it mean that if the fetch
|
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 The main two use-cases for additional fetches that I'm aware of are:
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 |
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: #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.
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 If you don't want to retry the push event by default (which imho is the best option) you could at least provide an
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 |
I'm still having a problem with the premise. You want multiple activations from the same push message. Of course that conflicts with I think that @beverloo was on the right course with the mention of background sync. That exists specifically to address this class of issue. You don't want multiple push message deliveries for the same message, you want a way to reactivate the service worker. Then, if the application server is down, you register with background sync to be awoken again after some time. |
Yes, I mean you should retry if an exception is triggered inside the
That may conflict with And in any case the background sync would only prevent network problems, while a retry on exceptions would also make
If I understand the spec correctly background sync will only allow to delay the execution until you get an internet connection. It is not meant as a way to execute retries for arbitrary exceptions... so you cannot use it to make your code resistant to application server errors (e.g. 503). |
Please consider thinking about an upgrade path. Including the payload with the push message itself is a much better and more reliable experience for users. One idea to quickly source keying material could be to upload the keys with your analytics ping when receiving a message, or when the user next visits the website.
There certainly are use-cases for push messages that don't carry a payload. They come with two downsides: lack of sender authentication (by not being able to validate the keying material) and reduced reliability if more data has to be fetched from the network. Introducing additional fetches definitely increases bandwidth as a full connection has to be established; RFC8030 includes a message receipt mechanism for acknowledgements, and many of the other push services provide similar functionality. Also something to consider is that push services are really good at delivering messages, even in networking conditions where other fetches might not go through.
Note that at least two implementations handle this by omitting the resources that can't be loaded rather than trying to fetch them again.
Unfortunately the availability of such functionality doesn't mean that it's Web compatible - if existing users of the Push API don't include a
The push messaging functionality might not be provided by the browser itself; several implementations will be limited by operating system constraints here.
Yeah, that is unlikely to work. The purpose of |
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 general it is valid to receive a 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:
I think that the
The above solution would be also "Web compatible" / backward compatible. Also I don't see any system constraints for a solution like this. |
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. I also believe that you can call ServiceWorkerRegistration.showNotification() inside a Background Sync. Am I wrong? Then the easiest approach to make the processing of the
You already recommend Background Sync for The only problem I can see in this approach is that |
Some more thinking...
Yes, you can use that. I have found that some blog posts (example) actually use it inside
Thinking about additional cases where you may want to use a fetch before displaying the notifications are the following:
Also talking about bandwidth usage of an additional fetch when
So Background Sync seems the perfect solution... the only worry is about
I think that you should define that more clearly (step by step) and allow notifications to be displayed indirectly by the |
There's a plethora of techniques that can be used for safely rolling out changes - slow roll-out, (targeted) A/B testing, and so on. We can't really help you with that problem.
You're right that an explicit opt-in approach wouldn't break existing users, but there still are other concerns. By sending a push message, developers have the ability to run JavaScript code on the user's device at a time of their choosing. This causes significant resource usage and is privacy sensitive, which is why various implementations require a notification to be shown. Now suppose that my Service Worker, unbeknownst to the user, runs the following code: self.addEventListener('push', event => {
// (1) Mine some cryptocurrency until the UA-defined time limit is reached.
event.retryUntil(new Promise((resolve, reject) => {
setTimeout(reject, GuessPushEventTimeLimit());
// Iteratively do stuff here.
}));
// (2) Would timeouts be considered as failures?
event.retryUntil(new Promise);
}); Suddenly the developer gets N execution opportunities for each notification that's been shown, which is a multiplication factor for these concerns. Variations on (1) could be to either retry forever until some UA-defined limit is reached, or execute this a few times before showing a notification. At that point we're effectively redesigning Background Sync, which is out of scope.
This is correct. Once permission has been granted, notifications can be shown from anywhere.
That's a fair concern - take a look at the https://wicg.github.io/cookie-store/
Because of the asynchronous and ephemeral nature of Service Workers, this actually is a really hard problem. It depends on the conditions of the device, requirements of the operating system and user agent, and the user experience decisions made by the browser vendor. To that end the specification doesn't detail how |
I think that you should define that to avoid future problems... Example: We decide to use Background Sync to fetch and display the notifications (the
I think that current browser implementation of In general I don't think that it is a big problem to attach two counters to a service worker registration in order to detect the number of push events and number of notification displayed. Even one counter is enough if you prefer... you can use +1 and -1 on the same counter and you make sure that it stays in a range around zero (e.g. [0, 10]). If a websites goes out of that range then you display a default notification to the user that informs him that the website is running in background... What are the pros? You can process the What are the cons? I don't see any problem. Privacy is preserved because a website cannot run in background without displaying notifications. IMHO if you don't allow to do that in the spec, the only effect will be to have worst code with the exact same effects (also for privacy!). If you follow my suggestion, then developers can use this confidently:
Otherwise they will write this (same effect as above... bad code):
|
Another reason for downloading the payload from the application server is that you get an additional layer of security (as I described here some years ago). If you send payloads through the push service, an attacker that manages to steal secret data from the application database (e.g. endpoints and keys), can send fraudulent notifications to end users. Instead, if you download notification content from the application server, the hackers won't be able to show any notification... they can only send useless push signals. |
I am testing the use of Web Background Sync... and I get this error on Chrome:
When the Is there anyone that can be contacted in order to change this behavior and allow |
In the working draft I cannot find anything about retries for the
push
event.When our service worker receives a
push
event it tries tofetch
the notifications from the application server. What if a network error occurs? (e.g. the user is on an unreliable network or the server is temporary down)I think that it would be useful to always retry the
push
event with exponential backoff when an exception occurs: what do you think? Currently I don't see any way for the developer to create a reliablepush
handler.The text was updated successfully, but these errors were encountered: