Interruptible tasks are terminated without being restarted

[niba]

Verify canary release

• I verified that the issue exists in the latest Turborepo canary release.

Link to code that reproduces this issue

do i need to?

What package manager are you using / does the bug impact?

pnpm

What operating system are you using?

Mac

Which canary version will you have in your reproduction?

Turborepo v2.2.4-canary.9

Describe the Bug

I have three persistent apps: app (nextjs), api (node), and worker (node). My node projects are marked as interruptible: true in the Turbo config.

I start my project using Turbo in watch mode. There are two different scenarios:

1. [WORKS] When I change a package that ALL my apps depend on, this scenario restarts interruptible apps correctly.
2. [DOESN'T WORK] When I change a package that SOME of my apps depend on. The issue affects tasks that don't depend on the modified package. If these tasks are marked as interruptible, they receive a SIGINT signal (exit code 130) and don't start again.

For example, when I change code in the Next.js app, my worker task changes the "progress icon status" to "done icon status" and the last log is:

My api task doesn't log anything and just hangs indefinitely. (it doesn't respond to any http requests etc so probably is killed)

I've tried different versions of Turbo, but none of them work.

Expected Behavior

If I change a task that is not a dependency of another persistent task, then the persistent task (marked as interruptible) should not receive SIGINT.

If this issue is difficult to fix, then at least add a restart mechanism for all interruptible tasks.

To Reproduce

Should be easy to reproduce in tests?

Additional context

No response

[choover-circle]

I reproduced this issue easily in this repo

All one should need to do is start with yarn dev --ui=tui, make changes to _app.tsx or similar file in next-app as simple as adding a comment, the express server will then die.

[choover-circle]

I also feel its worth sharing some logs, I ran with -vvv

2024-11-26T15:39:20.837-0800 [TRACE] log: signal: Want
2024-11-26T15:39:20.837-0800 [TRACE] log: signal: Want
next-app:dev:  ✓ Ready in 1390ms
2024-11-26T15:39:43.382-0800 [TRACE] tokio_util::codec::framed_impl: attempting to decode a frame
2024-11-26T15:39:43.382-0800 [TRACE] tokio_util::codec::framed_impl: frame decoded from buffer
2024-11-26T15:39:43.382-0800 [TRACE] tokio_util::codec::framed_impl: attempting to decode a frame
2024-11-26T15:39:43.382-0800 [DEBUG] turborepo_lib::process::child: stopping child process
2024-11-26T15:39:43.382-0800 [DEBUG] turborepo_lib::process::child: starting shutdown
2024-11-26T15:39:43.382-0800 [DEBUG] turborepo_lib::process: waiting for 2 processes to exit
2024-11-26T15:39:43.382-0800 [DEBUG] turborepo_lib::process::child: sending SIGINT to child 76537
2024-11-26T15:39:43.382-0800 [TRACE] turborepo_lib::process: process exited: Ok(Some(Finished(Some(0))))
2024-11-26T15:39:43.382-0800 [DEBUG] turborepo_lib::process::child: waiting for child 76537
express-app:dev: SIGINT signal received.
2024-11-26T15:39:43.389-0800 [TRACE] turborepo_lib::process::child: sending child exit
2024-11-26T15:39:43.389-0800 [DEBUG] turborepo_lib::process::child: child process stopped
2024-11-26T15:39:43.389-0800 [TRACE] turborepo_lib::process::child: exit channel was updated
2024-11-26T15:39:43.389-0800 [TRACE] turborepo_lib::process: process exited: Ok(Some(Killed))
2024-11-26T15:39:43.389-0800 [DEBUG] turborepo_lib::process: waiting for 0 processes to exit
2024-11-26T15:39:43.390-0800 [TRACE] turborepo_lib::run::watch: handling run with changed packages: Some({Other("next-app")})

Everything after next-app:dev: ✓ Ready in 1390ms was the result of changing the code in next-app.

sending SIGINT to child 76537

This is the log that killed the yarn dev in the express-server and I believe it shouldn't have been killed

https://gist.github.com/choover-circle/49ff56968127c34e41fca5914cf4d1d4

Here are the full logs

[choover-circle]

I temporarily fixed this using the new siblings functionality.
The node server is still setup as persistent but no longer interruptible. I then use siblings to run my build step with watch enabled in parallel while restarting the node server with nodemon.
Perhaps there's something causing the node server to be killed because it's set as interruptible?

[dmstoykov]

Another workaround that I found was to use the watch command from tsx to monitor and restart persistent, non-interruptible tasks. tsx watch (v4.19.2) also detects changes inside internal package dependencies of the watched package.