resource/helm_release: don't skip the uninstall when the release lookup fails

[bitte-ein-bit]

Rollback Plan

If a change needs to be reverted, we will publish an updated version of the library.

Changes to Security Controls

No changes to security controls.

Description

resourceReleaseExists returns false in two very different situations: the release really is gone, and the lookup against the cluster failed. The two are only distinguishable through the diagnostics it returns alongside the boolean.

Delete acts on the boolean before appending those diagnostics, so the error is discarded:

exists, diags := resourceReleaseExists(ctx, name, namespace, meta)
if !exists {
	return
}
resp.Diagnostics.Append(diags...)   // never reached in the error case

A failed lookup is therefore treated as "already uninstalled". Delete returns without an error, the framework removes the resource from state, and the uninstall never runs — the release is left behind in the cluster with nothing tracking it any more. Recovering means importing it again or cleaning up with helm by hand.

We ran into the underlying failure on AKS during a brief API server outage: the same hiccup surfaced in the kubernetes provider as

Error: Invalid configuration for API client
Get "https://…azmk8s.io:443/apis": net/http: TLS handshake timeout

which was retried and succeeded, while the helm provider swallowed it. It hit us on the Read path rather than Delete (a release was dropped from state and the next apply failed with cannot re-use a name that is still in use), but Delete has the same ordering and a worse outcome, since the release is not just untracked but silently left running.

This moves the diagnostics check ahead of the exists check, so a failed lookup surfaces as an error instead of being interpreted as absence. Create already handles it in this order.

Scope: the identical ordering issue in Read is already addressed in #1734, so this PR deliberately leaves Read alone to avoid a conflicting change. #1734 does not touch Delete; the two are complementary and can merge in either order.

Acceptance tests

• Have you added an acceptance test for the functionality being added?

No acceptance test: reproducing this requires the API server lookup to fail at a specific point during destroy, which the existing test harness has no hook for. Happy to add one if a maintainer can point at a suitable way to inject the failure.

Release Note

`resource/helm_release`: Fix `Delete` skipping the uninstall and dropping the resource from state when the release lookup fails because of a transient error (for example `net/http: TLS handshake timeout`), leaving the release behind in the cluster.

References

• fix(helm_release): Preserve Terraform state on failed Helm operations (#1669) #1734 — fixes the same ordering issue in Read
• v3 Provider appears to randomly remove helm_release resources from TF state - Hard to reproduce #1669 — the state-removal reports that led here

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[hashicorp-cla-app]

All committers have signed the CLA.

[hashicorp-cla-app]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

_{Have you signed the CLA already but the status is still pending? Recheck it.}