Configuring retry constraints to handle server outages

[asakusuma]

Broadly speaking, we'd be more likely to use background sync if we had more agency over the constraints of the retry behavior.

The three different scenarios I personally care about for sync:

1. User is offline
2. Server has an error
   a. Intermittent error
   b. Server is actually down for a significant period

The current spec behavior of always retrying when going online makes sense for the first use case.

Whenever the user agent changes to online, the user agent SHOULD fire a sync event for each sync registration whose registration state is pending.

But this might not be wanted for handling server errors. Ideally we could tailor the retry behavior to the different scenarios. One possible approach is to allow some configuration values in the rejection reason for the sync event (related to WICG/periodic-background-sync#3 (comment)).

This would allow us to respect a Retry-After response header. Or provide a larger buffer on a server error to prevent a self inflicted ddos event. (@jakearchibald side note, do you know if retry-after is automatically handled by chromium? as in, retry without background sync at all)

// If we get a 500 response, wait at least a day to retry
self.addEventListener('sync', function(event) {
  event.waitUntil(
    getQueuedRequest()
      .then((req) => fetch(req))
      .then((res) => {
        if (!res.ok) {
          if (Math.floor(res.status/100) === 5) {
            throw { minRetryWait: 1000 * 60 * 60 * 24 };
          }
          throw new Error('retry again whenever');
        }
      })
  );
});