Race condition on 2 sub Taskfile.yml if they define same var in certain situation

[lwintermelon]

Description

file list

├── sub1
│   └── Taskfile.yml
├── sub2
│   └── Taskfile.yml
└── Taskfile.yml

sub1/Taskfile.yml

version: "3"

vars:
  ENV_RAW_JSON:
    sh: |
      echo '{ "DATE": "2024-06-01"}'
  ENV_JSON:
    ref: fromJson .ENV_RAW_JSON
  DATE: '{{ index .ENV_JSON "DATE" }}'
tasks:
  print:
    cmds:
      - echo "DATE {{.DATE}}"

sub2/Taskfile.yml

version: "3"

vars:
  DATE:
    sh: echo "2024-06-01"
tasks:
  print:
    cmds:
      - echo "DATE {{.DATE}}"

top level Taskfile.yml

version: '3'

includes:
  sub1:
    taskfile: ./sub1/Taskfile.yml
    dir: ./sub1
  sub2:
    taskfile: ./sub2/Taskfile.yml
    dir: ./sub2

Then run task sub1:print at the top-level in a loop; you'll soon trigger a race condition like this.

# while task sub1:print; do :; done
task: [sub1:print] echo "DATE 2024-06-01"
DATE 2024-06-01
task: [sub1:print] echo "DATE 2024-06-01"
DATE 2024-06-01
task: [sub1:print] echo "DATE 2024-06-01"
DATE 2024-06-01
template: :1:3: executing "" at <index .ENV_JSON "DATE">: error calling index: index of untyped nil

Version

3.50.0+d61d92df

Operating system

Linux and Windows

Experiments Enabled

No response

Example Taskfile

[trulede]

I think here the problem is that DATE might take either of the imported values, exactly which one is not certain because the imports are evaluated non-deterministically (e.g. not necessarily in the order they are defined).

This is a known issue. Workaround is to "namespace" imported variables with a prefix, to avoid collisions in the global var space.

There is a PR #2659 addressing this.

[lwintermelon]

@trulede

I think here the problem is that DATE might take either of the imported values, exactly which one is not certain because the imports are evaluated non-deterministically (e.g. not necessarily in the order they are defined).

But it may get a nil, a uninitialiezd value.

This is a known issue. Workaround is to "namespace" imported variables with a prefix, to avoid collisions in the global var space.

What about env, according to my test, the env is also affected, the task sub1:print should be identical to task --dir sub1 print, but it isn't. The behavior is very counterintuitive. You starts with sub1 and sub2 then define a root Taskfile which imports both. In sub1 and sub2, everything works, but in root, it'll mess everything up, and what's worse is that the result is indeterministic .! It's something like dynamic scopes like Lisp, a fatal mistake, which makes includes not work at all.

Ok， for vars, at this moment, I can accept your workaround, but for envs, no way. for example, CGO_ENABLED.

There is a PR #2659 addressing this.

The env is also scoped?

[trulede]

Envars are also a common point of confusion.

You can manually namespace you global vars and then use coalesce to introduce some deterministic global var resolution.

[lwintermelon]

I mean diffirent sub Taskfile can have different default env var for CGO_ENABLED, it shouldn't affect each other, but it does.