Deno processes spawned using deno task do not exit when the parent process exits on Windows

[dhardtke]

Consider this example:

deno.jsonc:

{
  "tasks": {
    "script": "deno run script.ts",
  }
}

script.ts:

console.log(Deno.pid);
while (true);

reproduction.ts:

const BROKEN = ["task", "script"];
const WORKING = ["run", "script.ts"];

const command = new Deno.Command(Deno.execPath(), { args: BROKEN });
const parent = command.spawn();
console.log(`Spawned ${parent.pid}`);
await sleep();

parent.kill();

function sleep(): Promise<void> { return new Promise(resolve => { setTimeout(() => { resolve(); }, 1000); }); }

Here's the behavior using the BROKEN cmd in reproduction.ts:

> deno run --allow-all reproduction.ts 
Check file:///reproduction.ts
Spawned 15852
Warning deno task is unstable and may drastically change in the future
Task script deno run script.ts
2036

> taskkill /F /IM deno.exe             
SUCCESS: The process "deno.exe" with PID 15040 has been terminated.
SUCCESS: The process "deno.exe" with PID 2036 has been terminated.

Here's the same execution but this time using the WORKING cmd:

> deno run --allow-all reproduction.ts 
Check file:///reproduction.ts
Spawned 17712
17712

> taskkill /F /IM deno.exe             
ERROR: The process "deno.exe" not found.

deno 1.20.5 (release, x86_64-pc-windows-msvc)
v8 10.0.139.6
typescript 4.6.2

[dhardtke]

Maybe this issue belongs in https://github.com/denoland/deno_task_shell?

[Hexagon]

Following! Whats the status on this?

[StephenHaney]

I think I'm also running into this – It's possible this is why Deno.serve sometimes and says the address is already in use when in --watch mode (denoland/deno#16699)

For instance, right now my Deno.serve is still running even though I've exited out of the terminal that ran the deno task to start it.

[rmnoon]

I just ran into this as well! deno task mytask will drop me back to a shell on ctrl-c even though whatever script I executed in that task with deno run is still hanging. Threw me for a nasty loop today (no pun intended). The child script still gets the SIGINT, just nobody waits for him to complete.

EDIT: this is on MacOS 14.6.1 with Deno 1.46.1.

[cryptix]

Same here on Deno 2.0.x - We ran into this porting a nextjs project, and afiact deno task build spawns a lot of processes, maybe even one per page in the SSR / pre-render stage.. this easily eats the whole system memory after a few runs.

[mo]

Running into this is a really bad "first experience with deno" for people .... 😿

I created a git repo showing the problem I had.... note that "npm run docker-compose" works perfectly and "deno task docker-compose" breaks:

https://github.com/mo/deno-tasks-signal-issue-repro

[mo]

I guess npm run uses sh as a shell and there the behavior is to "kill all processes in the foreground process group":
https://www.reddit.com/r/node/comments/zddhcb/comment/iz3dkbg/
...and "npm run" is just looping over a list of processes and killing them here:
https://github.com/npm/run-script/blob/8e08311358a9f7c361e191b728eaada53eba607b/lib/signal-manager.js#L11

@dsherret did you attempt to fix this bug in PR #35 2.5 years ago but it never got merged or was that a different issue?
#35

[dsherret]

Let's keep this issue focused on Windows because Windows is very specific here and requires a solution like #35

For other operating systems, please follow: denoland/deno#18445 which has a pending solution in #131 (edit: and now at denoland/deno#27141)