Possible data loss with background sync

[engrtitus]

The way background sync works at the moment is

1. Receives sync event
2. Removes request from queue and retry
3. If retry fails, add request back to queue.

This works really well if the network strength is very good.

If the network strength is not (e.g 2g/edge network) .What might happen is.

1. Receives sync event.
2. Removes request from queue and retry.

While retrying...a user might close the tab or reload the page.

3. Request being retried never gets to server and never gets added back to the queue

[jeffposnick]

Hello @engrtitus!

In workbox-background-sync, the retry step happens inside of your service worker and is wrapped with event.waitUntil() (to prevent the service worker from stopped prematurely). Closing an active tab or reloading the current page should not interfere with the process of re-adding a failed request to the queue, since the service worker will still be running.

If you're seeing something different in the real world, please let us know, and we can revisit this issue. But assuming you were just talking hypotheticals, I don't think you need to worry.

[planeth44]

I've experienced data loss when network connectivity is bad. Not because the user closes the tab, but because the server times out or responds with a 500 status and the request is not requeued.
As I understand the request is added back in the queue if the fetch fails (meaning no network) but is there a mechanism to check for the response status ?

[jeffposnick]

Hello @planeth44—Sorry, this is an area that we should make clearer in our docs (I'll follow-up on that in a separate PR).

The BackgroundSyncPlugin uses the fetchDidFail callback function to queue up a retry. fetchDidFail will only be triggered if there's an exception thrown during the fetch(), which will normally happen if the network is unavailable. It won't happen by default if there's a network response with a 4xx or 5xx error status.

What I'd recommend doing if you want to retry on server errors is to add in a fetchDidSucceed plugin that will throw if the response status is 5xx (or 4xx... but I'm assuming you'd rather only retry 5xx errors?).

import {BackgroundSyncPlugin} from 'workbox-background-sync';
import {registerRoute} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';

const bgSyncPlugin = new BackgroundSyncPlugin('myQueueName', {
  maxRetentionTime: 24 * 60,
});

const statusPlugin = {
  fetchDidSucceed: ({response}) => {
    if (response.status >= 500) {
      // Throwing anything here will trigger fetchDidFail.
      throw new Error('Server error.');
    }
    // If it's not 5xx, use the response as-is.
    return response;
  },
};

registerRoute(
  '/api/',
  new NetworkOnly({
    plugins: [
      statusPlugin,
      bgSyncPlugin,
    ],
  }),
  'POST'
);

[planeth44]

@jeffposnick This makes sense! My bad for not reading the doc more thoroughly.
Thanks for the explanation

[lpeabody]

I'm running into an issue, and I think I've narrowed it. Related to:

const statusPlugin = {
  fetchDidSucceed: ({response}) => {
    if (response.status >= 500) {
      // Throwing anything here will trigger fetchDidFail.
      throw new Error('Server error.');
    }
    // If it's not 5xx, use the response as-is.
    return response;
  },
};

This works for fetches from the browser. However, when the Queue replays the request on a future sync this statusPlugin will not apply since fetch requests initiated from a service worker are not hooked into by the service worker. You also have to set the sync callback option when instantiating the background sync plugin.

https://github.com/GoogleChrome/workbox/blob/v7/packages/workbox-background-sync/src/Queue.ts#L360C5-L380C8