app-service: install on upgrade when the helm release is missing#3438
app-service: install on upgrade when the helm release is missing#3438pengpeng wants to merge 1 commit into
Conversation
An upgrade of an app whose helm release no longer exists (e.g. the release was lost while the ApplicationManager still believes the app is installed) fails with "release: not found" and drops the app into upgradeFailed, with no clean recovery path. Make upgrade self-heal a vanished release: - upgrading_app.go: tolerate driver.ErrReleaseNotFound from GetDeployedReleaseVersion instead of returning early; skip the ">= deployed version" guard when there is no deployed release. - helm.UpgradeCharts: mirror `helm upgrade --install`. action.Upgrade.Run does not honor the Install field (that lives in helm's CLI layer), so probe the release history and fall back to InstallCharts when it is ErrReleaseNotFound. Co-authored-by: Cursor <cursoragent@cursor.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 2f41098. Configure here.
| ctrl.Log.Info("helm release not found on upgrade; installing instead", | ||
| "appName", appName, "namespace", namespace) | ||
| return InstallCharts(ctx, actionConfig, settings, appName, chartName, repoURL, namespace, vals) | ||
| } |
There was a problem hiding this comment.
History errors silently ignored
Medium Severity
In UpgradeCharts, when hist.Run returns an error other than driver.ErrReleaseNotFound, that error is dropped and execution continues to runUpgrade. Elsewhere (e.g. HelmClient.IsInstalled, clearHelmHistory) non–not-found history failures are returned immediately, so callers may see a misleading upgrade failure or miss the install fallback when storage is unavailable.
Reviewed by Cursor Bugbot for commit 2f41098. Configure here.


When an app's helm release no longer exists but the
ApplicationManagerstill believes the app is installed (orphaned/incomplete prior install), anupgradefails early inUpgradingApp.execatGetDeployedReleaseVersionwithrelease: not foundand drops the app intoupgradeFailed. From thereupgradekeeps hitting the same error and there is no clean CLI recovery path.This PR makes
upgradeself-heal a vanished release instead of erroring:upgrading_app.go: toleratedriver.ErrReleaseNotFoundfromGetDeployedReleaseVersion(don't return early), and skip the>= deployed versionguard when there is no deployed release.helm.UpgradeCharts: mirrorhelm upgrade --install. helm'saction.Upgrade.Rundoes not honor theInstallfield (that behavior lives in helm's CLI layer), so probe the release history and fall back toInstallChartswhen it returnsdriver.ErrReleaseNotFound.go build ./...andgo vet ./pkg/helm/... ./pkg/appstate/...pass. (The helm path has no cluster-backed unit tests.)main
N/A
This is approach B (root-cause fix: upgrade reinstalls a missing release, so
upgradeFailednever happens for a vanished release). Approach A — #3437 — makesupgradeFailedrecoverable viainstallfrom the state machine side. The two are independent and can coexist; opened both so maintainers can pick the preferred direction (or take both).app-service is a core component; the change takes effect after app-service is rebuilt/redeployed.
Made with Cursor