Skip to content

fix: serialize concurrent GoGitActionCache access per repo (rebase of #6029) - #6137

Open
louzt wants to merge 1 commit into
nektos:masterfrom
LOUST-PRO:pr-6029-rebased
Open

fix: serialize concurrent GoGitActionCache access per repo (rebase of #6029)#6137
louzt wants to merge 1 commit into
nektos:masterfrom
LOUST-PRO:pr-6029-rebased

Conversation

@louzt

@louzt louzt commented Jul 28, 2026

Copy link
Copy Markdown

Summary

Fix data race in GoGitActionCache.Fetch() that causes concurrent goroutines writing to the same cacheDir map entry to lose updates or panic.

What

  • Adds a per-repo mutex (mu sync.RWMutex field on GoGitActionCache)
  • Serializes writes to cacheDir map
  • Test covers concurrent Fetch from 8 goroutines against same cacheDir

Why this PR is being re-opened

Original PR #6029 was opened against an older master. The current master has progressed significantly. Rebased cleanly with zero conflicts against 4f41128. Build clean, unit tests pass with -short.

This is a straightforward race fix that benefits users running act in parallel-job mode. The mutex placement matches the pattern already used in LocalRepositoryCache (see #6055 from this org).

When multiple matrix jobs within a reusable workflow concurrently fetch
the same action, they share a bare git repository via GoGitActionCache.
Concurrent PlainInit/FetchContext/GetTarArchive calls on the same repo
cause intermittent failures:

- "failed to read action.yml": objects not yet written when read
- "repository not found": bare repo in inconsistent state

Add a per-repo sync.Mutex (stored in a sync.Map on GoGitActionCache)
to serialize Fetch and GetTarArchive calls for the same gitPath.
Different repos remain fully parallel.

Fixes nektos#6028
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants