Re: [w3ctag/design-reviews] Extended lifetime shared workers (Issue #1089)

jyasskin left a comment (w3ctag/design-reviews#1089)

Personal, non-TAG opinion: `SharedWorker.runCleanupOnExit()` is nicer to type, but only if that's exactly the behavior the site wants. As y'all explored, it also changes the time that various work happens, and page-exit==navigation might be exactly the wrong time to do the work of spinning up a worker. So I now think that the original proposal is likely to be the right design to start with on the startup end. A function to start-on-exit seems like something that can be added later if developers need it.

On the exit end, I'd forgotten or never knew that there's a [`sharedWorkerGlobal.close()`](https://developer.mozilla.org/en-US/docs/Web/API/SharedWorkerGlobalScope/close) function, so the disagreement here is completely about what the default should be. A conscientious developer will write,

```javascript
port.onmessage = async (e) => {
  try {
      const { cryptoKey, analyticsData } = e.data;

      const encryptedData = await crypto.subtle.encrypt(
        { name: "AES-GCM", iv: new Uint8Array(12) }, 
        cryptoKey, 
        analyticsData
      );
      await fetch("/send-analytics", { method: "POST", body: encryptedData, keepalive: true });
  } finally {
    self.close();
  }
};
```

And get their SharedWorker shut down promptly. A forgetful developer will skip the `self.close()`, and quietly use ~30s of extra resources ... unless the browser notices that their script has no outstanding Promises or inbound open message pipes.

With a design based on `ExtendableEvent`, the forgetful developer might start by forgetting to extend their event, which will lead to occasional missed reports. Presumably they're watching for this, or they wouldn't have made an `extendedLifetime` SharedWorker in the first place. Then the next step is to extend the event as they want, and there's no simple way to accidentally ask for the whole 30s.

So ... I think I still lean toward the `ExtendableEvent` style over letting people call `self.close()`, even though it requires a new function that throws if called from the wrong kind of SharedWorker ... unless there's another angle that I'm still missing.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1089#issuecomment-3234242596
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1089/3234242596@github.com>