https://w3c.github.io/push-api/ says: > A user agent SHOULD invoke the Soft Update algorithm for the service worker registration in response to each failure so that errors in scripts can be corrected. https://github.com/w3c/push-api/issues/115 suggests triggering a soft update for all `push` events, but Martin noted some complications with that.
So, if you dispatch a push event we already do handle the update here: https://dxr.mozilla.org/mozilla-central/source/dom/workers/ServiceWorkerPrivate.cpp?q=ServiceWorkerPrivate.cpp&redirect_type=direct#463 That has a 24 hour time check, though. I guess you don't want that here? Calling MaybeScheduleUpdate() for failures would cause us to bypass that 24 hour check and shouldn't really cause any harm. Since we use a timer mechanism we should end up debouncing the updates pretty well already.
The 24-hour check is actually good to keep here. For push anyway. We don't want every push to generate network traffic (unless the worker asks for it, I guess). MaybeScheduleUpdate() sounds reasonable. We don't *want* to trigger a whole lot of 304s if there are lots of these, but there shouldn't be lots of failures (ideally). Bad workers are perhaps the main reason and a bad worker can generate a lot more work than a cache revalidation request.
Yeah, I think it's good to keep the 24-hour check for the success case. AIUI, the timer bypass is only for the case where the event handler throws, or the promise passed to `pushEvent.waitUntil` rejects.
You need to log in before you can comment on or make changes to this bug.