Bumping version of local chart results in inconsistent result error

[nint8835]

Terraform, Provider, Kubernetes and Helm Versions

Terraform version: 1.12.2
Provider version: 3.0.2
Kubernetes version: 1.33.0

Affected Resource(s)

• helm_release

Terraform Configuration Files

resource "helm_release" "repro" {
  name      = "issue-repro"
  chart     = "${path.module}/repro-chart"
  namespace = "default"
}

Debug Output

https://gist.github.com/nint8835/8873a73e875a53bab478c2eb5987b20f

Panic Output

N/A

Steps to Reproduce

A complete ready-to-go simple repro example can be found here: https://github.com/nint8835/helm-issue-repro

1. Create & apply a helm_release referencing a local helm chart
2. Update the version value on the chart
3. Apply again

Expected Behavior

The release be upgraded without issue

Actual Behavior

The apply fails due to an inconsistent result error, however the upgrade will complete successfully. On subsequent apply, Terraform will correctly recognize the updated state

│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to helm_release.repro, provider "provider[\"registry.terraform.io/hashicorp/helm\"]"
│ produced an unexpected new value: .metadata.revision: was cty.NumberIntVal(3), but now cty.NumberIntVal(4).
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to helm_release.repro, provider "provider[\"registry.terraform.io/hashicorp/helm\"]"
│ produced an unexpected new value: .metadata.version: was cty.StringVal("0.1.0"), but now
│ cty.StringVal("0.1.1").
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to helm_release.repro, provider "provider[\"registry.terraform.io/hashicorp/helm\"]"
│ produced an unexpected new value: .metadata.last_deployed: was cty.NumberIntVal(1.751334292e+09), but now
│ cty.NumberIntVal(1.751334361e+09).
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

Applies doing things like changing values do not cause this error, it is specifically updating the version in the local chart

Important Factoids

N/A

References

• Can't use version constraint #1662 - Exhibits a similar error on the version field, unsure if they have the same cause

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

[arybolovlev]

Hi @nint8835,

I am not able to reproduce the issue. Please share more specific steps.

Thank you.

[SomaticMaple]

I have the same problem, inconsistent result when updating version in chart YAML file. If there is any change in configuration of helm release, everything is fine.

[STollenaar]

same issue when following the steps. After I updated the version in the Chart.yaml getting this error:

[psychosoldier]

I have the same problem, when I change the version it fails and marks an error.

Version provider: + provider registry.opentofu.org/hashicorp/helm v3.0.2

│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to
│ helm_release.deployments["xxxxxx"], provider
│ "provider["registry.terraform.io/hashicorp/helm"].istio" produced an
│ unexpected new value: .metadata.version: was cty.StringVal("0.0.7"), but
│ now cty.StringVal("1.0.1").
│
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.

[scott-doyland-burrows]

Same here:

When applying changes to helm_release.this["ingress-class-ingress-nginx"], provider "provider[\"registry.terraform.io/hashicorp/helm\"].helm" produced an unexpected new value: .metadata.revision: was cty.NumberIntVal(1), but now cty.NumberIntVal(2).

If I alter the version in the chart I get the error and an apply fails. A second apply runs OK.

apiVersion: v2
name: ingress-class
version: 1.1.0
description: A Helm chart for Kubernetes IngressClass and IngressClassParams
type: application
appVersion: '1.0'

I think this needs a setting like the computed_fields for the kubernetes provider.

https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs/resources/manifest#optional

Or it should not be checking that value againt what it was originally at all - it should just alter it and not check it's previous value.

[scott-doyland-burrows]

Hi @nint8835,

I am not able to reproduce the issue. Please share more specific steps.

Thank you.

The OP's demo repo reproduces the issue for me:

https://github.com/nint8835/helm-issue-repro

I am running:

Terraform v1.12.2
on linux_amd64
+ provider registry.terraform.io/hashicorp/helm v3.0.2

helm_release.repro: Refreshing state... [id=issue-repro]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # helm_release.repro will be updated in-place
  ~ resource "helm_release" "repro" {
        id                         = "issue-repro"
        name                       = "issue-repro"
      ~ version                    = "0.3.0" -> "0.4.0"
        # (26 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

helm_release.repro: Modifying... [id=issue-repro]
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to helm_release.repro, provider "provider[\"registry.terraform.io/hashicorp/helm\"]" produced an unexpected new value: .metadata.revision: was cty.NumberIntVal(1), but now
│ cty.NumberIntVal(2).
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to helm_release.repro, provider "provider[\"registry.terraform.io/hashicorp/helm\"]" produced an unexpected new value: .metadata.last_deployed: was cty.NumberIntVal(1.752042342e+09),
│ but now cty.NumberIntVal(1.752042352e+09).
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to helm_release.repro, provider "provider[\"registry.terraform.io/hashicorp/helm\"]" produced an unexpected new value: .metadata.version: was cty.StringVal("0.3.0"), but now
│ cty.StringVal("0.4.0").
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

[helders]

I'm having the same issue too:

Terraform version 1.12.2

╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to module.jardineiros.helm_release.wordpress, provider "provider["registry.terraform.io/hashicorp/helm"]" produced an unexpected new value: .metadata.last_deployed: was
│ cty.NumberIntVal(1.752179494e+09), but now cty.NumberIntVal(1.752180796e+09).
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to module.jardineiros.helm_release.wordpress, provider "provider["registry.terraform.io/hashicorp/helm"]" produced an unexpected new value: .metadata.revision: was
│ cty.NumberIntVal(18), but now cty.NumberIntVal(19).
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

I was just updating the chart version, no other changes being applied.

[cwegener]

I used to have this problem all the time since using 3.0.1/3.0.2

Just now it stopped happening for the first time. And I successfully bumped a chart version without the inconsistent result error.

I wonder if it depends on the actual version values?

[RemcodM]

I can reproduce the same error in a somewhat different way. If I bump the version of a chart, and I apply the chart, but somehow the upgrade does not proceed within the timeout and the upgrade operations times out, then on the next apply of the chart I will always get these errors:

╷
│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to
│ module.kubernetes_prometheus_stack.helm_release.kube_prometheus_stack,
│ provider "provider[\"registry.terraform.io/hashicorp/helm\"]" produced an
│ unexpected new value: .metadata.last_deployed: was
│ cty.NumberIntVal(1.753795581e+09), but now
│ cty.NumberIntVal(1.753813943e+09).
│ 
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.
╵
╷
│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to
│ module.kubernetes_prometheus_stack.helm_release.kube_prometheus_stack,
│ provider "provider[\"registry.terraform.io/hashicorp/helm\"]" produced an
│ unexpected new value: .metadata.revision: was cty.NumberIntVal(125), but
│ now cty.NumberIntVal(126).
│ 
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.
╵

Like already said in previous messages, the upgrade does still proceed if I get these errors. After the upgrade I can apply for a third time and then I get no changes and also no errors.

[tamir-deep]

Reproduces for me as well on 3.0.2 provider version.
I installed a local chart with chartVersion: "1.0.0".
I updated the version to "1.1.0" and applied - failed during the apply although the upgrade seemed successful.
I reran apply and there were 0 changes to do.

[cwegener]

Quick update.

Just today I saw for the first time that this issue is not restricted to the version metadata.

This issue also affects the following helm metadata fields:

• revision
• last_deployed