1283618 - Trigger a service worker soft update for failed pushes

Status: RESOLVED WORKSFORME

(Core :: DOM: Push Subscriptions, defect, P3)

Description

[Lina Butler [:lina]]

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.

Comment 1

[Lina Butler [:lina]]

http://searchfox.org/mozilla-central/rev/261fe13dcd88cfd2e99e65755e7ca4b7a2e583df/dom/workers/ServiceWorkerRegistrationInfo.cpp#336-350 looks like it'll do the trick.

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

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.

Comment 3

[Martin Thomson [:mt:]]

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.

Comment 4

[Lina Butler [:lina]]

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.

Comment 5

[Andrew Sutherland [:asuth] (he/him)]

Consistent with the spec on functional events, we schedule a soft update check. Spec-wise, push explicitly invokes fire a functional event in step 6 of receiving a push message and fire functional event in the SW spec explicitly runs the soft update algorithm in the case of failure in step 5, and as part of step 8 in the success case. (Note that the time gating comes from "if registration is stale".)