Can a nested worker outlive its parent worker?

[andreubotella]

In Gecko, Blink and Deno, terminating a dedicated worker also terminates all of its child dedicated workers – which you can observe by logging into the dev console. It's not clear that this is allowed by the spec as it is right now.

Per the "closing orphan workers" step in the worker event loop, when a worker's owner set is empty, its closing flag is set to true. However, DedicatedWorkerGlobalScopes doesn't seem to be removed from any child workers's owner sets when the worker is closed, and a worker's owner set is not a weak set, so there is never a point when a nested worker has its owner set empty.

However, even if worker global scopes were removed from child workers when they're closed, that still would not match implementations, because setting the closing flag doesn't abort the current script – whereas Gecko seems to kill the nested worker immediately, and Blink and Deno after a 2s delay. (Blink and Deno's implementation of worker.terminate() is also to set the closing flag and then kill the worker after 2s: see denoland/deno#12658 (comment))

You could argue that this is unobservable from user code, since dedicated nested workers have no way to communicate with the outside (the dev console doesn't count, after all). However, this is not true, since workers can modify state which is shared with the document, such as URL.revokeObjectURL.

And here we come to the most perplexing part of all of this: error handling. The specified error handling for dedicated workers has unhandled errors propagating upwards the nested worker chain, even if some of the workers in the middle have terminated. This seems at odds with nested workers being killed when their parent closes. I guess this could be interpreted to cover the timeout after the parent closes, as well as errors thrown while the parent is closing, but without a note to that effect, that seems to read as if nested workers can survive their parents' death.

IMO not removing the current DedicatedWorkerGlobalScope from child workers's owner sets is a clear bug, but killing the nested worker's script after some timeout should also be covered. This could be specified on the worker event loop, or it could be specified by having dedicated workers be terminated when the Worker object and any relevant event listeners get GC'd.