Can a Service Worker finish in-flight work before a new version takes control?

Short answer

No — there is no drain or quiesce primitive in the Service Worker spec. skipWaiting() only shortens the waiting phase; nothing asks the old worker to finish its fetch handlers, Background Sync tasks, or IndexedDB transactions, and there is no standard API to query its in-flight count or idle state. The reliable approach is a cooperative postMessage handshake that you build yourself.

What actually happens at cutover

The old worker is not killed mid-task the instant the new one activates. Extendable events keep it alive via waitUntil() until pending promises settle. But once the new worker controls the clients, the old worker stops receiving new events — so a long sync task may finish in a worker that no longer owns anything, which is usually fine for idempotent writes and dangerous for anything that assumes continued control.

The handshake pattern

The standard cooperative pattern looks like this:

1. The old worker maintains an in-flight counter: increment in fetch/sync handlers, decrement on settle. IndexedDB transactions can't be paused mid-transaction, so check the counter only at transaction boundaries.
2. The new worker, during install, messages clients (which relay to the old worker) with a drain-request.
3. The old worker sets a draining flag, stops accepting new logical work, waits for the counter to hit zero, then replies drained.
4. Only then does the new worker call skipWaiting().

// old worker
let inFlight = 0, draining = false;
self.addEventListener('message', async (e) => {
  if (e.data === 'drain-request') {
    draining = true;
    while (inFlight > 0) await new Promise(r => setTimeout(r, 50));
    e.source.postMessage('drained');
  }
});

This is voluntary cooperation, not an atomic cutover: a tab opened mid-deploy can still be claimed by the new worker while old tabs run the old one, so your fetch handlers still need version-mismatch tolerance.

If activation fails after claiming

If the new worker throws during activate or its script fails evaluation, the browser discards it. A still-alive old worker keeps controlling its clients — tabs are not left controller-less. If the old worker was already terminated, clients become uncontrolled until reload; there is no automatic rollback to a previous version.

Verification

Because controllerchange timing differs across Chrome, Firefox, and Safari, make the handshake event-driven, never timeout-based. Test with an instrumented build: log the in-flight counter, trigger an update mid-sync, and confirm in DevTools (Chrome: Application > Service Workers; Firefox: about:debugging) whether the old worker's tasks settle before controllerchange fires. Simulate failure by throwing in the new worker's activate handler and checking whether existing tabs retain the old controller. One caveat worth flagging for review: exact worker termination heuristics are browser-specific and shift between releases, so re-verify on each major browser update.