Inside a service worker, what does event.waitUntil(promise) do in the install and activate events, and what goes wrong if you start async work without it?

## Service workers are event-driven and disposable The first thing to internalise is that a service worker has no guaranteed lifetime. The browser spins it up when there is an event to deliver, and once the event handlers have returned it is entitled to shut the worker down — it may do so within seconds to save memory. Any `async` work you kicked off and did not declare is at risk of being cut off mid-flight, and global variables you set do not survive the restart. `ExtendableEvent.waitUntil(promise)` is the declaration. It is available on the lifecycle events (`install`, `activate`) and on functional events derived from `ExtendableEvent` such as `push` and `sync`. The related method on `FetchEvent` is `respondWith()`, which extends the event's lifetime as well as supplying the response. ## In the install event ```js self.addEventListener('install', (event) => { event.waitUntil(setup()); }); ``` Three things follow: 1. **The worker stays alive** until `setup()` settles. 2. **The state transition waits.** The worker stays *installing* and only becomes *installed* when the promise fulfils. 3. **Rejection fails the install.** If the promise rejects, the installation is abandoned: the new worker becomes *redundant* and never activates. Crucially, the previously active worker is untouched and keeps controlling pages. This is the mechanism that makes installation atomic — you can do your setup work knowing that a partial failure will not leave a half-ready worker in charge. That last property is why setup work belongs in `install` behind `waitUntil` rather than being fired off and forgotten. "Fetch all the things I need, and if any of it fails, don't become the app's worker" is exactly the guarantee you want. ## In the activate event ```js self.addEventListener('activate', (event) => { event.waitUntil(migrate()); }); ``` During activation the worker is in the *activating* state. Functional events are not dispatched to it while `waitUntil` is pending — the browser holds them until the promise settles and the worker reaches *activated*. That is the window in which it is safe to do cleanup or data migration that would confuse a request handler if it ran concurrently. Note the asymmetry with install: a rejected `activate` promise does **not** roll the worker back; it activates anyway. `waitUntil` in `activate` buys you ordering, not atomicity. ## What omitting it looks like ```js // Bug: nothing is waited on self.addEventListener('install', async () => { await slowSetup(); // may never finish }); ``` An `async` handler returns a promise, but the event does not look at the handler's return value — only at what you pass to `waitUntil`. So the browser sees an empty handler, marks the worker installed, and is free to terminate it. On a fast desktop connection the work usually completes and the bug hides; on a slow phone the worker gets killed mid-setup and activates in a broken state. The symptom is the classic "works on my machine, broken for 3% of users". ## Practical rules - Pass **one** promise. Multiple `waitUntil` calls are allowed and are all awaited, but the common shape is a single async IIFE: ```js event.waitUntil((async () => { … })()); ``` - Call it **synchronously** inside the handler. Calling `waitUntil` after an `await` — once the event has already finished dispatching — throws an `InvalidStateError`, because by then the extension window has closed. - Do not treat it as "keep my worker alive forever". Browsers impose their own cap on how long an event may be extended and will terminate a worker that overruns it, so `waitUntil` is for bounded setup work, not for background loops. - Keep install work minimal and required-only. Everything in the `waitUntil` promise is on the critical path to the new worker becoming usable, and every optional fetch you add is another way for the install to fail.