Race condition between concurrent Task processes when cloning remote Git Taskfiles

[QuentinBtd]

Description

Description

Task intermittently fails while cloning a remote Git Taskfile when multiple Task processes run concurrently.

This occurs in normal development workflows, where Task may be invoked by an IDE extension, shell completion, or another terminal at the same time.

Error

failed to clone repository: error downloading 'https://example.com/example.git?depth=1&ref=v1.2.0': /usr/bin/git exited with 128: Cloning into '/private/tmp/task-git-repos/git/<repository-cache-key>'...
error: could not lock config file /private/tmp/task-git-repos/git/<repository-cache-key>/.git/config: No such file or directory
error: could not lock config file /private/tmp/task-git-repos/git/<repository-cache-key>/.git/config: No such file or directory
fatal: could not set 'core.repositoryformatversion' to '0'

Example Taskfile

version: '3'

includes:
  remote:
    taskfile: https://example.com/example.git//tasks/example/taskfile.yaml?ref=v1.2.0

Steps to reproduce

1. Clear the remote Taskfile cache so that the Git repository needs to be cloned.
2. Run multiple Task processes concurrently:

task --list &
task --list &
wait

3. Repeat if necessary, as the failure is intermittent.

Expected behavior

Concurrent Task processes should resolve the remote Git Taskfile successfully.

Actual behavior

One or more processes intermittently fail during Git repository initialization because .git/config is no longer present.

Environment

• Task version: 3.53.1
• Operating system: macOS
• Architecture: arm64
• Remote Taskfile transport: Git over HTTPS

Version

3.53.1

Operating system

macOS

Experiments Enabled

No response

Example Taskfile

version: '3'

includes:
  remote:
    taskfile: https://example.com/example.git//tasks/example/taskfile.yaml?ref=v1.2.0

[trulede]

You would need something like https://github.com/gofrs/flock to create a "lock file" while the include is cached.

[xinnyuli]

I'd like to take this one, using gofrs/flock as suggested.

Before I start: is the intended lock scope the whole cache directory,
or per-repository (keyed by the cache key)? Per-repo would let unrelated
includes clone in parallel, but I want to check that against how the
cache is laid out today.