fix: add mutex lock for concurrent rewriteChartDependencies access by yxxhero · Pull Request #2509 · helmfile/helmfile

yxxhero · 2026-03-31T13:48:47Z

Summary

Add per-chart-path mutex (sync.Map) to prevent race conditions when multiple goroutines concurrently call rewriteChartDependencies on the same chart path
Restore original Chart.yaml content under the mutex lock to ensure atomicity
Add race condition test (TestRewriteChartDependencies_RaceCondition) that runs 10 concurrent goroutines

Why

rewriteChartDependencies modifies Chart.yaml (rewrite relative file:// deps to absolute paths) and later restores it via a cleanup function. When multiple goroutines operate on the same chart path concurrently, this can cause data races and corrupted file content.

Testing

TestRewriteChartDependencies_RaceCondition: 10 goroutines concurrently rewrite the same chart, verifying no errors and Chart.yaml remains valid
Existing tests continue to pass

Signed-off-by: yxxhero [email protected]

Copilot

Pull request overview

Adds per-chart locking around rewriteChartDependencies to prevent concurrent goroutines from corrupting Chart.yaml during dependency rewrite + restore, and introduces a concurrency-focused regression test.

Changes:

Introduce a per-chartPath mutex map (sync.Map) and lock rewriteChartDependencies to serialize access per chart.
Restore the original Chart.yaml content under the same lock via the returned cleanup function.
Add TestRewriteChartDependencies_RaceCondition running 10 concurrent goroutines on the same chart directory.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
`pkg/state/state.go`	Adds per-chart mutex + locking around `rewriteChartDependencies` to prevent concurrent modification/restore races.
`pkg/state/chart_dependencies_rewrite_test.go`	Adds a concurrent test intended to detect regressions in rewrite/restore under contention.

Copilot · 2026-03-31T13:54:56Z

+	mu := st.getChartDepsMutex(chartPath)
+	mu.Lock()
+
 	// Read Chart.yaml
 	data, err := os.ReadFile(chartYamlPath)
 	if err != nil {
+		mu.Unlock()
 		return func() {}, err
 	}


The mutex is acquired at the start of rewriteChartDependencies, but most later error returns (e.g. yaml.Unmarshal failure, filepath.Abs failure, yaml.Marshal / os.WriteFile failures) return cleanup, err without executing cleanup. Callers like processChartification return immediately on error and do not invoke the returned cleanup, which would leave the per-chart mutex locked forever and deadlock subsequent calls for the same chartPath. Please ensure the mutex is always released on any error path after Lock() (e.g., by invoking cleanup before returning the error and returning a no-op cleanup, or by explicitly Unlock() on error returns).

Copilot · 2026-03-31T13:54:57Z

+	// Verify Chart.yaml is still valid
+	data, err := os.ReadFile(chartYamlPath)
+	if err != nil {
+		t.Fatalf("failed to read Chart.yaml: %v", err)
+	}
+
+	// Should still have the dependencies section
+	if !strings.Contains(string(data), "dependencies:") {
+		t.Errorf("Chart.yaml should still have dependencies section")
+	}


This test says it verifies Chart.yaml "is still valid", but the assertion only checks for the substring "dependencies:", which could still pass with partially corrupted YAML. To actually validate correctness of the concurrent rewrite/restore behavior, consider unmarshaling the file (using the same yaml package as production, github.com/helmfile/helmfile/pkg/yaml) and asserting expected fields/dependencies are present.

yxxhero · 2026-03-31T13:56:35Z

@copilot review and update code.

Copilot · 2026-03-31T14:14:43Z

@copilot review and update code.

Both issues have been addressed in commit e23df21:

Mutex deadlock fix (pkg/state/state.go): On all error paths after mu.Lock() (yaml.Unmarshal failure, filepath.Abs failure, yaml.Marshal failure, os.WriteFile failure), the mutex is now explicitly unlocked and a no-op cleanup function is returned. This prevents callers that return on error without calling cleanup from permanently deadlocking subsequent calls on the same chart path.
Test improvement (pkg/state/chart_dependencies_rewrite_test.go): TestRewriteChartDependencies_RaceCondition now properly unmarshals Chart.yaml using github.com/helmfile/helmfile/pkg/yaml and validates specific expected fields — chart name, dependency count, dependency name, and repository prefix — instead of a weak substring check.

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

Comments suppressed due to low confidence (1)

pkg/state/state.go:1519

When modified is false, the mutex remains locked until the returned cleanup runs (and cleanup rewrites the file). This serializes concurrent callers on the same chart even though no rewrite was needed. Consider unlocking and returning a no-op cleanup when no changes are made, keeping the long-held lock only for the rewrite+restore case.

	// Write back if modified
	if modified {
		updatedData, err := yaml.Marshal(&chartMeta)
		if err != nil {
			mu.Unlock()
			return func() {}, fmt.Errorf("failed to marshal Chart.yaml: %w", err)
		}

		if err := os.WriteFile(chartYamlPath, updatedData, 0644); err != nil {
			mu.Unlock()
			return func() {}, fmt.Errorf("failed to write Chart.yaml: %w", err)
		}

		st.logger.Debugf("Rewrote Chart.yaml with absolute dependency paths at %s", chartYamlPath)
	}

	return cleanup, nil
}

Copilot · 2026-04-01T00:33:16Z

@@ -1417,7 +1417,18 @@ type PrepareChartKey struct {
 //
 // When running `helmfile template` on helm v2, or `helmfile lint` on both helm v2 and v3,
 // PrepareCharts will download and untar charts for linting and templating.


The PrepareCharts doc comment block now sits immediately above chartDepsMutexMap, so Go will treat it as the doc comment for that variable (and it no longer documents PrepareCharts). Add a blank line (non-comment) to break the association and/or move this mutex map + helper closer to rewriteChartDependencies with its own comment.

Suggested change

// PrepareCharts will download and untar charts for linting and templating.

// PrepareCharts will download and untar charts for linting and templating.

Copilot · 2026-04-01T00:33:16Z

+var chartDepsMutexMap sync.Map
+
+func (st *HelmState) getChartDepsMutex(chartPath string) *sync.Mutex {
+	mu, ok := chartDepsMutexMap.Load(chartPath)
+	if ok {
+		return mu.(*sync.Mutex)
+	}
+	newMu := &sync.Mutex{}
+	actualMu, _ := chartDepsMutexMap.LoadOrStore(chartPath, newMu)
+	return actualMu.(*sync.Mutex)


This introduces a second global keyed-mutex map (chartDepsMutexMap/getChartDepsMutex) even though the file already has the same pattern with rwMutexMap/getNamedRWMutex (pkg/state/state.go:1391-1404). Consider reusing the existing map (e.g., via getNamedRWMutex + Lock) or generalizing to avoid duplicated keyed-lock infrastructure.

Suggested change

var chartDepsMutexMap sync.Map

func (st *HelmState) getChartDepsMutex(chartPath string) *sync.Mutex {

mu, ok := chartDepsMutexMap.Load(chartPath)

if ok {

return mu.(*sync.Mutex)

}

newMu := &sync.Mutex{}

actualMu, _ := chartDepsMutexMap.LoadOrStore(chartPath, newMu)

return actualMu.(*sync.Mutex)

func (st *HelmState) getChartDepsMutex(chartPath string) *sync.RWMutex {

return getNamedRWMutex(chartPath)

Copilot · 2026-04-01T00:33:17Z


 		if err := os.WriteFile(chartYamlPath, updatedData, 0644); err != nil {
-			return cleanup, fmt.Errorf("failed to write Chart.yaml: %w", err)
+			mu.Unlock()
+			return func() {}, fmt.Errorf("failed to write Chart.yaml: %w", err)
 		}


On os.WriteFile(chartYamlPath, updatedData, ...) failure, the file may have been truncated/partially written. The current error path unlocks and returns without attempting to restore originalContent, which can leave a corrupted Chart.yaml behind. Restore the original content under the mutex before returning (or write atomically via temp file + rename).

Copilot · 2026-04-01T00:33:17Z

+	// Run multiple goroutines concurrently on the same chart path
+	numGoroutines := 10
+	var wg sync.WaitGroup
+	errCh := make(chan error, numGoroutines)
+
+	for i := 0; i < numGoroutines; i++ {
+		wg.Add(1)
+		go func() {
+			defer wg.Done()
+
+			logger := zap.NewNop().Sugar()
+			st := &HelmState{
+				logger: logger,
+				fs:     filesystem.DefaultFileSystem(),
+			}
+
+			cleanup, err := st.rewriteChartDependencies(tempDir)
+			if err != nil {
+				errCh <- err
+				return
+			}
+			defer cleanup()
+		}()
+	}
+
+	wg.Wait()
+	close(errCh)


This race test starts goroutines immediately, but it doesn’t coordinate a simultaneous start, so it may not reliably create contention on all systems. Consider adding a start barrier (e.g., a channel that all goroutines wait on) so the calls to rewriteChartDependencies overlap deterministically and the test is less flaky/weak.

yxxhero · 2026-04-01T00:35:47Z

@copilot review comments and update code.

Copilot · 2026-04-01T00:50:27Z

@copilot review comments and update code.

All four review comments addressed in commit 451a961:

Doc comment misplacement + duplicate mutex (state.go:1419, 1420-1429): Removed chartDepsMutexMap and getChartDepsMutex entirely. rewriteChartDependencies now reuses the existing getNamedRWMutex (calling mu.Lock() for exclusive write access), consistent with how acquireExclusiveLock already uses it. This also naturally resolves the doc comment misplacement.
Restore on os.WriteFile failure (state.go:1509-1513): If writing the updated Chart.yaml fails, the original content is now restored before unlocking. The warning log message includes both the original write error and the restore error for full diagnostic context.
Start barrier in race test (chart_dependencies_rewrite_test.go:530-556): Added a ready channel; all goroutines block on <-ready before calling rewriteChartDependencies, then close(ready) releases all of them simultaneously to maximize contention.

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

Copilot · 2026-04-01T07:06:19Z

@@ -1440,6 +1434,7 @@ func (st *HelmState) rewriteChartDependencies(chartPath string) (func(), error)
 		if err := os.WriteFile(chartYamlPath, originalContent, 0644); err != nil {
 			st.logger.Warnf("Failed to restore original Chart.yaml at %s: %v", chartYamlPath, err)
 		}
+		mu.Unlock()
 	}


rewriteChartDependencies acquires mu.Lock() unconditionally and the returned cleanup always rewrites Chart.yaml and unlocks later. In the common case where modified is false (no relative file:// deps), callers like processChartification still defer the cleanup, which (a) holds the per-path lock across the entire chartify run and (b) touches Chart.yaml (mtime change + unnecessary IO) even though nothing was changed. Consider unlocking immediately and returning a no-op cleanup when no rewrite is needed, and only restoring/writing the original content (and holding the lock until deferred cleanup) when the file was actually modified.

Copilot · 2026-04-01T07:06:20Z

+	// Verify Chart.yaml is still valid by unmarshaling and checking expected fields
+	data, err := os.ReadFile(chartYamlPath)
+	if err != nil {
+		t.Fatalf("failed to read Chart.yaml: %v", err)
+	}
+
+	type ChartDependency struct {
+		Name       string `yaml:"name"`
+		Repository string `yaml:"repository"`
+		Version    string `yaml:"version"`
+	}
+	type ChartMeta struct {
+		APIVersion   string            `yaml:"apiVersion"`
+		Name         string            `yaml:"name"`
+		Version      string            `yaml:"version"`
+		Dependencies []ChartDependency `yaml:"dependencies,omitempty"`
+	}
+
+	var chartMeta ChartMeta
+	if err := yaml.Unmarshal(data, &chartMeta); err != nil {
+		t.Fatalf("Chart.yaml is not valid YAML after concurrent rewrites: %v", err)
+	}
+
+	if chartMeta.Name != "test-chart" {
+		t.Errorf("expected chart name 'test-chart', got %q", chartMeta.Name)
+	}
+	if len(chartMeta.Dependencies) != 1 {
+		t.Fatalf("expected 1 dependency, got %d", len(chartMeta.Dependencies))
+	}
+	if chartMeta.Dependencies[0].Name != "dep1" {
+		t.Errorf("expected dependency name 'dep1', got %q", chartMeta.Dependencies[0].Name)
+	}
+	if !strings.HasPrefix(chartMeta.Dependencies[0].Repository, "file://") {
+		t.Errorf("expected dependency repository to start with 'file://', got %q", chartMeta.Dependencies[0].Repository)
+	}


This race-condition test only checks that Chart.yaml remains valid YAML and that the dependency repository starts with file://. It will still pass if the file is left in the rewritten (absolute) state or otherwise not restored correctly, since both states are valid YAML and match the prefix check. To validate the intended atomic rewrite+restore behavior, assert the final file contents (or at least the dependency repository) matches the original file://../relative-chart after all goroutines complete (and ideally increase iterations/contention to make regressions more likely to surface).

yxxhero · 2026-04-01T07:19:45Z

@copilot fix comments

Copilot · 2026-04-01T07:53:25Z

@copilot fix comments

Both reviewer comments addressed in commit d8580cf:

Early unlock when unmodified (state.go): When no relative file:// deps are found (modified == false), the mutex is now released immediately and a no-op cleanup is returned — the lock is never held past this call in that path. Only when the file is actually rewritten is the lock held until the deferred cleanup restores the original content.
Exact restore assertion in race test: The final check now asserts repository == "file://../relative-chart" (the exact original value) instead of just strings.HasPrefix(..., "file://"). This catches any scenario where the rewrite was not properly restored.

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

Copilot · 2026-04-12T05:46:16Z

-		if err != nil {
-			return cleanup, fmt.Errorf("failed to marshal Chart.yaml: %w", err)
-		}
+	// If nothing changed, release the lock immediately – no file I/O or lock held by caller needed.


The comment says "no file I/O" on the no-op path, but Chart.yaml has already been read (and unmarshaled) before this check. Consider rewording to clarify that no write occurs (and the mutex isn’t held beyond the function) when nothing is modified.

Suggested change

// If nothing changed, release the lock immediately – no file I/O or lock held by caller needed.

// If nothing changed, release the lock immediately. Chart.yaml has already been read and unmarshaled,

// but no file write is needed and the lock is not held beyond this function.

Copilot · 2026-04-12T05:46:16Z

+	// Run multiple goroutines concurrently on the same chart path.
+	// A start barrier ensures all goroutines attempt rewriteChartDependencies simultaneously.
+	numGoroutines := 10
+	var wg sync.WaitGroup
+	errCh := make(chan error, numGoroutines)
+	ready := make(chan struct{})
+


The "start barrier" here doesn’t actually ensure all goroutines are waiting before they’re released (closing ready happens without waiting for every goroutine to reach <-ready>). This reduces contention and can make the race test less effective. Consider adding a readiness counter (e.g., an additional WaitGroup/channel) before closing ready, and/or structuring the test to keep the rewritten state around long enough to force overlap in the pre-fix implementation (or assert that concurrent calls block until cleanup runs).

yxxhero · 2026-04-13T00:06:08Z

@copilot fix ci issue.

Copilot · 2026-04-13T00:16:04Z

@copilot fix ci issue.

Addressed in commit 4a3302d:

Rewrote the comment at state.go:1476 to clarify that Chart.yaml has already been read/unmarshaled but no file write occurs and the lock is not held beyond the function on the unmodified path.
Strengthened the race test start barrier with a readyWg sync.WaitGroup — each goroutine calls readyWg.Done() before blocking on <-ready, and the main goroutine calls readyWg.Wait() before closing ready. This guarantees all goroutines are already blocked at the barrier when it's released, maximizing contention.

Prevent race conditions when multiple goroutines concurrently access the same Chart.yaml by introducing a per-chart-path mutex via sync.Map. Signed-off-by: yxxhero <[email protected]> Signed-off-by: yxxhero <[email protected]>

…validation Agent-Logs-Url: https://github.com/helmfile/helmfile/sessions/135e06b8-99e8-42cb-859d-524b2d2b1907 Co-authored-by: yxxhero <[email protected]>

…failure, add test barrier Agent-Logs-Url: https://github.com/helmfile/helmfile/sessions/f93746bf-82fa-46b1-b8f0-b34bc9aa749c Co-authored-by: yxxhero <[email protected]>

Agent-Logs-Url: https://github.com/helmfile/helmfile/sessions/5981aea4-2799-4560-9272-315d28d4b7d7 Co-authored-by: yxxhero <[email protected]>

Agent-Logs-Url: https://github.com/helmfile/helmfile/sessions/9e4d6f4f-cdc1-4e9e-bdc6-81061ebc1dcc Co-authored-by: yxxhero <[email protected]>

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

Copilot · 2026-04-13T00:22:21Z

+	// Reuse the existing per-path RWMutex for exclusive access to the chart directory.
+	mu := st.getNamedRWMutex(chartPath)
+	mu.Lock()
+


The mutex key uses the raw chartPath string, but the file path operated on is filepath.Join(chartPath, "Chart.yaml") (which is cleaned). Equivalent paths like "/tmp/chart" vs "/tmp/chart/" (or paths containing "."/"..") can map to the same Chart.yaml while using different mutex keys, allowing concurrent rewrites despite the lock. Consider normalizing the key (e.g., filepath.Clean and/or filepath.Abs/EvalSymlinks) before calling getNamedRWMutex.

Copilot · 2026-04-13T00:22:21Z

+			cleanup, err := st.rewriteChartDependencies(tempDir)
+			if err != nil {
+				errCh <- err
+				return
+			}
+			defer cleanup()
+		}()


This race test defers cleanup() immediately after rewriteChartDependencies returns, so without any work between rewrite and cleanup the window for overlap is extremely small. That can make the test flaky/ineffective at reproducing the original corruption (which typically happens when the rewritten Chart.yaml is kept in place while other goroutines enter). Consider adding a small delay or some simulated chart processing between acquiring the cleanup and calling it (or looping the rewrite/cleanup a few times) to make concurrent overlap deterministic.

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

champtar · 2026-04-13T12:02:38Z

@yxxhero the right fix IMO would be to copy the Chart, here you can still corrupt the local Chart if helmfile exit / the system crash before we restore the original.

yxxhero · 2026-04-13T12:22:03Z

@champtar PR is welcome.

yxxhero requested review from aditmeno, itscaro, mumoshu, xiaomudk and zhaque44 as code owners March 31, 2026 13:48

yxxhero force-pushed the fix/rewrite-chart-deps-race-condition branch from 31df9a6 to 11a328b Compare March 31, 2026 13:49

yxxhero requested a review from Copilot March 31, 2026 13:50

Copilot AI reviewed Mar 31, 2026

View reviewed changes

yxxhero linked an issue Mar 31, 2026 that may be closed by this pull request

helmfile race condition when using rewriteChartDependencies #2502

Closed

Copilot started work on behalf of yxxhero March 31, 2026 13:56 View session

Copilot finished work on behalf of yxxhero March 31, 2026 14:17

yxxhero requested a review from Copilot April 1, 2026 00:29

Copilot started reviewing on behalf of yxxhero April 1, 2026 00:30 View session

Copilot AI reviewed Apr 1, 2026

View reviewed changes

Copilot started work on behalf of yxxhero April 1, 2026 00:35 View session

Copilot finished work on behalf of yxxhero April 1, 2026 00:51

yxxhero requested a review from Copilot April 1, 2026 07:01

Copilot started reviewing on behalf of yxxhero April 1, 2026 07:02 View session

Copilot AI reviewed Apr 1, 2026

View reviewed changes

Copilot started work on behalf of yxxhero April 1, 2026 07:19 View session

Copilot finished work on behalf of yxxhero April 1, 2026 08:00

javajawa added a commit to javajawa/helmfile-2515 that referenced this pull request Apr 3, 2026

Demo/test for helmfile/helmfile#2509

cf0e2df

yxxhero requested a review from Copilot April 12, 2026 05:41

Copilot started reviewing on behalf of yxxhero April 12, 2026 05:41 View session

Copilot AI reviewed Apr 12, 2026

View reviewed changes

Copilot started work on behalf of yxxhero April 13, 2026 00:06 View session

Copilot finished work on behalf of yxxhero April 13, 2026 00:16

yxxhero requested a review from Copilot April 13, 2026 00:18

Copilot started reviewing on behalf of yxxhero April 13, 2026 00:18 View session

yxxhero and others added 5 commits April 13, 2026 08:20

fix: early unlock when unmodified, assert exact restore in race test

9685c14

Agent-Logs-Url: https://github.com/helmfile/helmfile/sessions/5981aea4-2799-4560-9272-315d28d4b7d7 Co-authored-by: yxxhero <[email protected]>

fix: improve comment wording and strengthen race test start barrier

a1c90de

Agent-Logs-Url: https://github.com/helmfile/helmfile/sessions/9e4d6f4f-cdc1-4e9e-bdc6-81061ebc1dcc Co-authored-by: yxxhero <[email protected]>

yxxhero force-pushed the fix/rewrite-chart-deps-race-condition branch from 4a3302d to a1c90de Compare April 13, 2026 00:20

Copilot AI reviewed Apr 13, 2026

View reviewed changes

yxxhero requested a review from Copilot April 13, 2026 00:52

Copilot started reviewing on behalf of yxxhero April 13, 2026 00:53 View session

Copilot AI reviewed Apr 13, 2026

View reviewed changes

xiaomudk approved these changes Apr 13, 2026

View reviewed changes

yxxhero merged commit acb7ce3 into main Apr 13, 2026
20 checks passed

yxxhero deleted the fix/rewrite-chart-deps-race-condition branch April 13, 2026 03:59

	// PrepareCharts will download and untar charts for linting and templating.
	// PrepareCharts will download and untar charts for linting and templating.

	// If nothing changed, release the lock immediately – no file I/O or lock held by caller needed.
	// If nothing changed, release the lock immediately. Chart.yaml has already been read and unmarshaled,
	// but no file write is needed and the lock is not held beyond this function.

Uh oh!

Uh oh!

Conversation

yxxhero commented Mar 31, 2026

Summary

Why

Testing

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Mar 31, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 31, 2026

Choose a reason for hiding this comment

Uh oh!

yxxhero commented Mar 31, 2026

Uh oh!

Copilot AI commented Mar 31, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Apr 1, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 1, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 1, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 1, 2026

Choose a reason for hiding this comment

Uh oh!

yxxhero commented Apr 1, 2026

Uh oh!

Copilot AI commented Apr 1, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Apr 1, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 1, 2026

Choose a reason for hiding this comment

Uh oh!

yxxhero commented Apr 1, 2026

Uh oh!

Copilot AI commented Apr 1, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Apr 12, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 12, 2026

Choose a reason for hiding this comment

Uh oh!

yxxhero commented Apr 13, 2026

Uh oh!

Copilot AI commented Apr 13, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Apr 13, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 13, 2026

Choose a reason for hiding this comment