Handle Service Worker ⚙ Termination ❌[Solution] 👍

Last Updated - Sat Jan 09 2021

Are you receiving the message in the Edge or Chrome console?

"service worker termination by a timeout timer was canceled because DevTools is attached"

Are you worried you have added something bad to your service worker?

There is no need to worry, this is an 'information' message Chrome and Edge log. Don't worry, it does not indicate anything is wrong with your code or logic.

This message is more to do with how the browser Dev Tools work than anything else.

However, it does raise the question, how long does a service worker live, or how long is the service worker life cycle?

How a Service Worker's Life Span is Determined

Not to be confused with the Service Worker Life Cycle, the time a browser keeps a site's service worker active once it has been triggered varies by browser and is what we are discussing here.

When a user opens a page associated with a registered service worker and the service worker is not active the browser instantiates the service worker. It runs in its own thread, technically external to the page. To conserve resources only one instance of the service worker is created and all associated pages use the single instance.

Even if a page is open in a tab, it may be idle, which means there is no need for a service worker to be active. If it were active excess CPU, memory and other resources are tied up when they are not needed. This means the user's battery drains faster than it needs and no one wants that.

Each browser uses it on calculations to determine when to kill an active, but unused service worker. There is no magic time in seconds when a service worker dies. It could be a minute or 30 minutes for all I know.

Evidently Chrome tries to terminate idle service workers at 30 seconds.

The specification states the following:

A user agent may terminate service workers at any time it:

Has no event to handle
Detects abnormal operation: such as infinite loops and tasks exceeding imposed time limits (if any) while handling the events

My guess is each browser does some sort of internal calculation based on available resources, if the device is using the battery or plugged in, etc. Something similar to how it determines how much storage space is available to a domain.

We do know browsers can and should aggressively kill unused service workers to optimize the device's performance.

Don't worry about breaking your application. If the service worker is dead and the user triggers it again the browser just spins up a fresh instance. This process is very quick and should not be noticeable to your customer.

Why Chrome Displays The Warning Message

Chrome and Edge detects when DevTools are open and does not kill the service worker ass aggressively. The browser assumes a developer is using DevTools and might be debugging service worker's code. Killing the service worker would cause all sorts of hair pulling and trust me we do that enough as it is.

The past few versions of Chrome have added the "service worker termination by a timeout timer was canceled because DevTools is attached" message to the work flow. This is done as a courtesy to help developers realize what they are debugging may not be exactly what the user would experience.

For developers the number one issue is relying on the persistence of global state. I am not an advocate of leaning heavy or even medium on global state as a value reference. I teach, always assume the service worker is being freshly instantiated.

This is not unique to service workers, I have seen abusive use of global state almost my entire career. Personally I see the MVVM pattern (think Angular) is the most abusive pattern and leads to large memory footprints and poor performance. Plus you must write more code (in my experience) than you would if you relied on hydrating what you need for the page.

The programming model is similar to how you should use when developing AWS Lambdas or Azure Functions. Write code that executes statically and assume nothing is preset before execution. Its OK to use some 'global' variables, but don't over use them.

As a developer you may experience scenarios where you think you are updating globally scoped values, but because the service worker is not terminated as you expected they are not. This can lead to wasted time troubleshooting why your new code is not performing as expected. You may need to explicitly terminate the service worker in the DevTools.

I do this often as well as manually unregistering service workers because they get into jacked up states after I make several layers of changes during a development cycle (what I call when I sit down for a few hours with my headphones jamming and my mind focused).

Unregister a Service Worker in the DevTools

This does not mean you should not create global variables in your service worker, it just means be smart about what you are declaring.

Service Worker is not responding

Another, related message you might see in the console is "service worker is not responding".

This is common if you are sitting on a break point for a long period of time. I have seen this message a few times, typically when I see some broken code and start down a set of rabbit trails updating the code or some other distraction interrupts my focus.

We have all been there.

I find it is best to kill the debug instance and sort of start fresh after making the changes anyway. So don't let this one freak you out either.

Should You Worry About a Terminated Service Worker?

Don't freak out if a user sits on a page or leave the tab open in the background. Your service worker will go dormant. As soon as the user loads a new page, refreshes a page, triggers a network request or an external trigger like a push notification happens the service worker springs back to life.

Similar to an AWS Lambda or Azure function service workers go from dormant to active almost instantly. Personally I think this is typically a 5-10ms latency. It could be more, but that is my rough observations over the past few years.

You could stress over a dormant state, but this is not a good use of your resources because service workers are designed to be there when you need them.

Summary

The "service worker termination by a timeout timer was canceled because DevTools is attached" is a courtesy message to help developers know the service worker experience they are testing against may not reflect what a production user experiences. If you see this and you want to make sure your service worker performs as expected you should think about running the progressive web app without the DevTools open.

Of course you should always test as your real users would experience your applications. This means you should also test on real mobile devices, like a $100 phone from Walmart over a 3G network. But just closing the DevTools can be a good first pass to flesh out common issues.