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

I'm deploying a small PWA where the Service Worker handles fetch caching and a long-running Background Sync task. When a new SW version ships, it installs in parallel but normally waits for all clients of the old worker to close. Using skipWaiting() with clients.claim() forces immediate activation, which is attractive for zero-downtime updates — but my concern is what happens to fetch handlers, sync tasks, or IndexedDB transactions the old worker started.

From what I can tell, the spec offers no drain or quiesce primitive: no way to ask the old worker to finish critical work before yielding, and no standard API to query how many clients it still controls or whether it is idle. Libraries like Workbox wrap the update flow, but they still rely on voluntary cooperation rather than an atomic cutover.

Assume current stable Chrome, Firefox, and Safari, whose controllerchange timing reportedly differs.

Is there any documented mechanism — or a reliable postMessage-based handshake pattern — for the new worker to wait until the old one reports no in-flight operations before calling skipWaiting()? And if the new worker fails activation after claiming clients, what is the expected recovery behavior for those tabs?