Provider produces inconsistent final plan when value in set refers to unknown value that actually doesn't change after apply

[shakhovski]

Terraform, Provider, Kubernetes and Helm Versions

Terraform version: 0.14.11 and 1.1.3
Provider version: 2.4.1
Kubernetes version: 1.22.4

Affected Resource(s)

• helm_release

Terraform Configuration Files

terraform {
  required_providers {
    helm = {
      source  = "hashicorp/helm"
      version = ">= 1.2"
    }
  }
}

provider "helm" {
  kubernetes {
    config_context = "docker-desktop"
  }
}

locals {
	values = {
		"value1" = "A"
		"value2" = random_string.unknown_value.result == "AAA" ? random_string.unknown_value.result : "AAA"
	}
}

resource random_string unknown_value {
	length = 8
}

resource helm_release release {
	name	= "test-chart"
	chart	= "C:/workspace/sandbox/helm-provider/test-chart-0.1.0.tgz"
	
	dynamic set {
		for_each = local.values
		content {
			name  = set.key
			value = set.value
		}
	}
}

Debug Output

N/A

Panic Output

N/A

Steps to Reproduce

1. terraform apply
2. terraform taint random_string.unknown_value
3. terraform apply

Expected Behavior

The third apply should work out without any issues.

Actual Behavior

The third apply fails with the error

Error: Provider produced inconsistent final plan

When expanding the plan for helm_release.release to include new values learned
so far during apply, provider "registry.terraform.io/hashicorp/helm" produced
an invalid new value for .set: planned set element
cty.ObjectVal(map[string]cty.Value{"name":cty.StringVal("value1"),
"type":cty.NullVal(cty.String), "value":cty.StringVal("A")}) does not
correlate with any element in actual.

This is a bug in the provider, which should be reported in the provider's own
issue tracker.

Important details

1. Dynamic set must contain at least one static value besides unknown one(s).
2. Unknown value must stay the same after apply.
3. The 'set' block must not contain 'type' attribute.

This is not an abstract case. We faced it when passing fqdn of postgres server to helm which is not changed after server gets recreated.

Available workarounds:

1. Define 'type' attribute explicitly with "", "auto" or "string".
2. Move blocks with unknown values to 'set_sensitive' (without any statically defined values).

RCA

For the third apply

1. When provider builds plan for the first time it considers 'type' attribute as removed since it is nil in Config yet "" in State.
   

   terraform-provider-helm/vendor/github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema/schema.go

   Line 1406 in ac4d18c

   removed = true

   
   So that planned change for 'value1' is:

name = "value1"
value = "A"
type = nil

2. When provider applies values learned during apply, it turns out that in fact there are no any changes and provider just gets the actual state.
   

   terraform-provider-helm/vendor/github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema/grpc_provider.go

   Line 725 in 72939a9

   resp.PlannedState = req.PriorState

   
   So that actual change for 'value1' is:

name = "value1"
value = "A"
type = ""

These changes are considered as incompatible by terraform
https://github.com/hashicorp/terraform/blob/792aa4562987e1cdbbf137a6c7d1dd1c652b8265/terraform/eval_diff.go#L87

Important Factoids

N/A

References

N/A

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

[djakielski]

I also run into that issue. My workaround was to taint changed helm_releses and recreate it.

[djakielski]

But after successfull apply, changes comes again and also errors. So in the end, not really a work around.

I hope that your pull request will released quick, because it is a blocker for me.

[SteveTalt]

We also have this issue. Basically, a taint fixes it temporarily but we basically have to taint it every other time we apply a change to this cluster.

[scole66]

We had this issue. Added type = on all of our "dynamic-set" and "set" blocks, and the trouble vanished.

[github-actions]

Marking this issue as stale due to inactivity. If this issue receives no comments in the next 30 days it will automatically be closed. If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. This helps our maintainers find and focus on the active issues. Maintainers may also remove the stale label at their discretion. Thank you!