(bug) Fix HelmReleaseSummary.FailureMessage never persisted#1693
Merged
gianlucam76 merged 1 commit intoprojectsveltos:mainfrom Apr 5, 2026
Merged
(bug) Fix HelmReleaseSummary.FailureMessage never persisted#1693gianlucam76 merged 1 commit intoprojectsveltos:mainfrom
gianlucam76 merged 1 commit intoprojectsveltos:mainfrom
Conversation
Member
Author
status:
dependencies: no dependencies
featureSummaries:
- consecutiveFailures: 1
failureMessage: |
chart: ingress-nginx, release: nginx, context deadline exceeded
featureID: Helm
hash: Ckr8tUz78ZCxNGIA/lR5QmvKVBZpFzuNCcjlUq/mE7k=
lastAppliedTime: "2026-04-05T15:01:36Z"
status: Failed
helmReleaseSummaries:
- failureMessage: context deadline exceeded
releaseName: nginx
releaseNamespace: nginx
status: Managing
- releaseName: postgres-operator
releaseNamespace: postgres-operator
status: Managing
valuesHash: yj0WO6sFU4GCciYUBWjzvvfqrBh869doeOC2Pp5EI1Y=
nextReconcileTime: "2026-04-05T15:01:46Z" |
…rt deployment failure When a Helm chart deployment fails, setHelmFailureMessageOnHelmChartSummary correctly sets FailureMessage on clusterSummary.Status.HelmReleaseSummaries[i] in memory, but this value was never written back to the API server. The root cause is a sequencing issue: updateStatusForReferencedHelmReleases (which persists HelmReleaseSummaries) runs before walkChartsAndDeploy. After walkChartsAndDeploy fails and sets the FailureMessage in memory, updateStatusForNonReferencedHelmReleases then re-fetches a fresh ClusterSummary from the API and overwrites the status, so discarding the in-memory change entirely. As a result, HelmReleaseSummaries[].FailureMessage always remained empty even after repeated failures, while featureSummaries[].failureMessage (set through a separate path) correctly reflected the error. A secondary bug: setHelmFailureMessageOnHelmChartSummary was passed currentChart (the raw, pre-template spec) instead of instantiatedChart. The lookup compares ReleaseName/ReleaseNamespace against values stored in HelmReleaseSummaries, which are the instantiated values. When those fields contain Go templates, the lookup would silently find no match and the FailureMessage would not be set at all. Fix consist in: 1. Pass instantiatedChart (post-template) instead of currentChart to setHelmFailureMessageOnHelmChartSummary so the lookup always matches what is stored in HelmReleaseSummaries. 2. In updateStatusForNonReferencedHelmReleases, before overwriting the status with the freshly fetched ClusterSummary, build an index of the in-memory FailureMessage values set by walkChartsAndDeploy and merge them into the entries being written. This ensures the failure from the current reconciliation round is persisted to the API.
405dcf1 to
87d2a41
Compare
Member
Author
|
Test added to functional verification |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When a Helm chart deployment fails, setHelmFailureMessageOnHelmChartSummary correctly sets FailureMessage on clusterSummary.Status.HelmReleaseSummaries[i] in memory, but this value was never written back to the API server.
The root cause is a sequencing issue: updateStatusForReferencedHelmReleases (which persists HelmReleaseSummaries) runs before walkChartsAndDeploy. After walkChartsAndDeploy fails and sets the FailureMessage in memory, updateStatusForNonReferencedHelmReleases then re-fetches a fresh ClusterSummary from the API and overwrites the status, so discarding the in-memory change entirely.
As a result, HelmReleaseSummaries[].FailureMessage always remained empty even after repeated failures, while featureSummaries[].failureMessage (set through a separate path) correctly reflected the error.
A secondary bug: setHelmFailureMessageOnHelmChartSummary was passed currentChart (the raw, pre-template spec) instead of instantiatedChart. The lookup compares ReleaseName/ReleaseNamespace against values stored in HelmReleaseSummaries, which are the instantiated values. When those fields contain Go templates, the lookup would silently find no match and the FailureMessage would not be set at all.
Fix consist in:
Fixes #1692