`task package` hangs with task >= 3.43.1

[haiqi96]

Bug

When running task package with task version >= 3.43.1, the task command hangs indefinitely.
With some initial investigation, it seems the issue is caused by building any python components, but it's not clear which part of code has caused the issue.

The issue can be work around by using a lower version of task (3.42.0). But since we don't limit the task version in our user docs, we should not ignore this issue.

CLP version

1f70d17

Environment

Ubuntu 22.04.

Reproduction steps

sh -c "$(curl --location https://taskfile.dev/install.sh)" -- -d 3.43.1
./bin/task clp-py-utils

Note: clp-package-utils and job-orchestration also causes hang.

[hoophalab]

Commenting out the line - "{{.PACKAGE}}/**/*" prevents the hang on task >= 3.43.1, though I'm not sure what the root cause of this bug is.

[haiqi96]

Commenting out the line - "{{.PACKAGE}}/**/*" prevents the hang on task >= 3.43.1, though I'm not sure what the root cause of this bug is.

Thanks for pointing this out!

[junhaoliao]

Debug setup

To investigate the issue, i install go-task with debug info: go install -gcflags="all=-N -l" github.com/go-task/task/v3/cmd/task@latest.

Investigation

1. By using go-lang debugger Delve to inspect the newest go routine's frames and args, it was found that the process is stuck at reading some very long path outside of the project directory. e.g., /mnt/c/Documents and Settings/All Users/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Logishrd/LogiOptionsPlus/Plugins/CEP/LogiOptionsPlusAdobe/node_modules/es5-ext/test/iterable
2. strace -e openat -p <PID> helped confirmed that whenever task is run, task looks into directories from the system's root /.
   Through the Delve debugger, it was found this task is giving us the hang issue:
   

   clp/taskfile.yaml

   Lines 533 to 544 in d63d8cb

   	python-component:
   	internal: true
   	label: "{{.COMPONENT}}"
   	vars:
   	PACKAGE:
   	sh: "echo {{.COMPONENT}} | tr - _"
   	VENV_DIR: "{{.G_BUILD_DIR}}/{{.COMPONENT}}/venv"
   	requires:
   	vars: ["COMPONENT"]
   	sources:
   	- "{{.G_BUILD_DIR}}/{{.COMPONENT}}_venv.md5"
   	- "{{.PACKAGE}}/**/*"

Speculation

it was found that the PACKAGE variable in "{{.PACKAGE}}//*" was not expanded properly, causing the value to be possibly resolved as "//*". Removing the line allows task to run without hang.

Further confirmation

It happened that i looked into go-task/task#2073 recently and its fix go-task/task#2075 rang me a bell. By installing with that specific commit and the one before that commit, it was confirmed that go-task/task#2075 caused the issue in erroneous variable expansion in sources.

here's a minimal reproduction with the latest task release 3.44.1:

tasks:
  task-1:
    vars:
      PARENT:
        sh: "echo PARENT"
    sources: ["{{.PARENT}}/**/*"]
    cmds:
      - echo "Task-1 {{.PARENT}}/**/*"

  task-2:
    vars:
      PARENT: "PARENT"
    sources: ["{{.PARENT}}/**/*"]
    cmds:
      - echo "Task-2 {{.PARENT}}/**/*"


  task-3:
    vars:
      PARENT:
        sh: "echo PARENT"
    sources: ["PARENT/**/*"]
    cmds:
      - echo "Task-3 {{.PARENT}}/**/*"

you may optionally create some test files with below structure though it doesn't really matter unless you want to confirm what files are looked at with strace:

<test-project>
  - Taskfile.yaml
  - PARENT
    - 123

Observation:

1. task task-1 hanged. (strace confirmed that it looked into many files from the root)
2. task task-2 ran successfully. (strace confirmed that it looked into PARENT).
3. task task-3 ran successfully. (strace confirmed that it looked into PARENT).

Mitigation

For now, i'll submit a simple fix to avoid referencing any dynamic variables (sh) in any sources.

Further actions

With some more further investigation, we should report the bug to go-task

[junhaoliao]

The issue is now reported to go-task/task#2400