Extract debug logs - Custom logger function

[AlexandreBonaventure]

Library Affected: workbox@^3.4.0

Browser & Platform: "all browsers" Context: Hi, We are using workbox (mostly to leverage offline capabilities/perf optimization) at our company to ship an embedded web application. The thing is, every time we are pushing an update, a small percentage of our customers is being caught in a broken app. The issue is hard to track down because we are running in a variety of hardware setups and since the app is embedded in a native one, the only way to solve the problem is to tell them to delete their cache folder inside their file system.

This is far from ideal. We already are using Stackdriver centralized logging solution for our services. So we thought: how about sending workbox debug logging in order to monitor what exactly is going on ? Is there any way to provide a custom logging function ? So we could hit https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry

My proposal if not :

workbox.setConfig({
  loggerFn(log) {
     // format log
      fetch(loggingEndpoint, {
         method: 'POST',
         ...
      })
  },
})

Thanks

[jeffposnick]

Have you considered using a global error handler in the window context to capture and report back problems? If there's something that fails to load due to service worker issues, then presumably there will also be an error event fired on the page.

You should be able to set up a similar handler inside of the ServiceWorkerGlobalScope too, I'd expect. Workbox will, I think, log issues and then propagate the underlying error on until it triggers any global error handlers in the service worker, rather than swallowing the errors. So tapping into Workbox's logging shouldn't be necessary.

But... taking a step back, let's see if we can narrow down some possible causes that would explain what you're describing. If you're seeing these issues around the time you're deploying updates, that sounds related to the service worker lifecycle.

Does you service worker use skipWaiting? Do you lazy-load assets with hashes in their URLs that might have been purged from the precache as a result of the new service worker skipping the waiting phase and immediately activating?

[AlexandreBonaventure]

Thanks for the feedback, We already are tracking errors via services like Sentry, so yes we have that kind of tool, and a global error handler that is working. We already have some report for example of error like this Failed to update a ServiceWorker: ServiceWorker script evaluation failed This is very sporadic but I don't think this is the cause of the issue, because it happens very randomly, and I would think this would just prevent the update (not break the current service worker/application)

However, what I am looking for here, is more a log-oriented report because I am not looking for thrown exceptions. I want to know what happened in terms of file served from the service worker when updating. In short, some customers are saying they are seeing the application without CSS. So I assume there was a problem serving the actual file (wheter it was not available in cache for some reason or ...), meanwhile this could not be tracked down as an thrown error.

Is that making sense ?

ps: https://github.com/GoogleChrome/workbox/issues/1528 if you want to see my config, I already filed an issue here. In short we are using skipWaiting but we are reloading immediately, we don't need to prompt the user here because it is an embedded app.

Thank you so much for your help! It is really appreciated!

[jeffposnick]

Sorry, I didn't realize the connection with #1528. We can follow up there.

Failed to update a ServiceWorker: ServiceWorker script evaluation failed

is the sort of error you'd see when there's a syntax error that prevents the service worker's top-level code from executing. (Here's a trivial example of forcing it to happen.)

I'm not aware of any reason why Workbox would emit a service worker with a syntax error in it, and if it did, the code that you're trying to use to set up logging would probably not actually execute, so I think that's a non-starter.

Is there something about your web hosting environment that might cause a certain percentage of your HTTP requests for your sw.js file to return invalid results? Like, are you using any sort of proxies that might rewrite responses?

[AlexandreBonaventure]

It's alright ! As far as I know, no fancy server config, we are using a battle-tested nginx/node docker image. The config is very straight forward and it sets no-cache headers to prevent service worker browser caching. However, since we are using navigateFallback I can easily see the service worker being serve as the index.html if it is not found on the server for whatever reason. Thus, raising the issue!

[tomayac]

Hi there,

Workbox is moving to a new engineering team within Google. As part of this move, we're declaring a partial bug bankruptcy to allow the new team to start fresh. We realize this isn't optimal, but realistically, this is the only way we see it working. For transparency, here're the criteria we applied:

• For PRs, we closed everything that doesn't target the current v7 branch.
• For Issues, we closed everything that was created before 2024.

Thanks, and we hope for your understanding! The Workbox team