go-task
undetected dependency loop or deadlock with `run: when_changed`
Description
In the example Taskfile.yml below, running task "hangs" forever. Okay, I didn't actually wait forever. But it hangs for long enough for you to think it's in an infinite loop or deadlock. If you remove run: when_changed, you get what you would expect:
task: Maximum task call exceeded (1000) for task "default": probably an cyclic dep or infinite loop
but the presence of run: when_changed or run: once is preventing this check from triggering.
I'm not really sure what the right behavior should be. My first thought was that it there should be proper loop detection rather than reliance on call depth, though I think limiting call depth is still important. But then I thought, well, if x only runs once, I might think the sequence should be default -> x -> default: default tries to run x, which tries to run default, which doesn't run x because it's run: once. But of course x didn't actually ever run. It only got invoked. So...you could make run: once or run: when_changed consider the task to have been run once it was invoked even if it hasn't finished, but I feel like maybe proper loop and deadlock detection may be best. I haven't looked at the code, so this is all speculation. Take it or leave it. You know the code. :-)
Version
3.44.0
Operating system
multiple
Experiments Enabled
No response
Example Taskfile
version: '3'
tasks:
default:
deps:
- x
x:
run: when_changed
deps:
- default
@jberkenbilt You might like to checkout and try PR #2287, I think I wrote a test similar to your scenario (I would try it myself but I've run out of codespace credits for this month ...).
@trulede I tested your PR, and with it, I see
task: Cyclic task call execution detected for task "default" (calling task "x")
which I consider to be a very helpful response. So for anyone watching this issue, #2287 fixes this issue as well as the one it is connected to. Thanks!