`turbo watch` hangs when running multiple persistent tasks with mixed interruptible settings

[WipeAir]

Verify canary release

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

Link to code that reproduces this issue

https://github.com/WipeAir/turborepo-repro-mixed-interruptable-tasks

Which canary version will you have in your reproduction?

2.8.21-canary.9

Environment information

CLI:
   Version: 2.8.21-canary.9
   Path to executable: xxx/node_modules/@turbo/darwin-arm64/bin/turbo
   Daemon status: Running
   Package manager: berry

Platform:
   Architecture: aarch64
   Operating system: macos
   WSL: false
   Available memory (MB): 8762
   Available CPU cores: 14

Environment:
   CI: None
   AI agent: None
   Terminal (TERM): xterm-256color
   Terminal program (TERM_PROGRAM): iTerm.app
   Terminal program version (TERM_PROGRAM_VERSION): 3.6.8
   Shell (SHELL): /bin/zsh
   stdin: false
   Node.js version: v24.14.0

Expected behavior

Running turbo watch start:dev in a monorepo with multiple persistent tasks (some with interruptible: true, some without) should start all tasks concurrently after their dependencies complete.

Both app-a (interruptible) and app-b (non-interruptible) should be running simultaneously.

Actual behavior

Only the first interruptible persistent task starts. The second persistent task (whether interruptible or not) never begins.

To Reproduce

1. Clone the repo and run yarn install
2. Run turbo watch start:dev
3. Observe that only one app's start:dev task starts (printing "app-a running" or "app-b running")
4. The second app's start:dev never starts -> the watch event loop is blocked

turbo.json uses a mix of interruptible and non-interruptible persistent tasks:

• app-a#start:dev: persistent + interruptible (simulates NestJS backend)
• start:dev (base): persistent, non-interruptible (simulates Vite frontend)

This setup worked prior to v2.8.15, though dependency ordering was sometimes incorrect. Since v2.8.15 this configuration no longer works at all.

Additional context

No response

[anthonyshew]

Hey, sorry about this! Fixed in the PR above.