Отмена дребезга асинхронной работы внутри обработчика событий сервисного работника

Немного сложно полностью отладить это, не видя вашего примера кода, но общее практическое правило заключается в том, что если вы планируете асинхронную работу, которую вы хотите выполнить вне синхронного выполнения обработчика событий сервис-воркера, вам нужно

• запланировать эту работу изнутри ExtendableEvent и
• оберните работу, передав обещание о ее завершении методу waitUntil() этого ExtendableEvent.

(FetchEvent — это ExtendableEvent.)

Если вы этого не сделаете, то браузер не гарантирует, что ваша асинхронная задача будет завершена до того, как рабочий поток службы будет уничтожен. Различные браузеры более или менее агрессивно подходят к завершению рабочего потока службы, поэтому это может объяснить различное поведение, которое вы наблюдаете.

Lodash debounce() не предлагает встроенной поддержки обещаний, поэтому вам придется либо обернуть вещи самостоятельно или найдите подходящую альтернативную библиотеку. Просто обратите внимание, что какой бы подход вы ни использовали, убедитесь, что вы используете промисы, которые в конечном итоге разрешатся, даже если операция будет отклонена. В противном случае, если вы передадите промис, который не разрешается в waitUntil(), вы в конечном итоге оставите работника службы в живых слишком долго.

Если оставить в стороне фактическую реализацию возвращающего обещание debounceWithPromises(), общая структура будет выглядеть так:

self.addEventListener('fetch', (event) => {
  if (/* some criteria is met */) {
    // As soon as the promise passed to respondWith() resolves,
    // the response will start being fed to the client.
    event.respondWith(generateResponse(event);

    // Independent of the response generation, the promise returned
    // by the hypothetical debounceWithPromises() will keep the
    // service worker alive until it resolves or rejects (or until a
    // browser-specific maximum lifetime is reached).
    event.waitUntil(debounceWithPromises(logStats));
  }
});