Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Terraform ignores changes to empty string value in azurerm_app_configuration_key #24565

Closed
1 task done
JiriKovar opened this issue Jan 19, 2024 · 3 comments · Fixed by #24582
Closed
1 task done

Terraform ignores changes to empty string value in azurerm_app_configuration_key #24565

JiriKovar opened this issue Jan 19, 2024 · 3 comments · Fixed by #24582

Comments

@JiriKovar
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment and review the contribution guide to help.

Terraform Version

1.7.0

AzureRM Provider Version

3.88.0

Affected Resource(s)/Data Source(s)

azurerm_app_configuration_key

Terraform Configuration Files

resource "azurerm_app_configuration_key" "setting" {
  configuration_store_id = azurerm_app_configuration.appconf.id
  key                    = "testkey"
  label                  = "label"
  value                  = ""

  lifecycle {
    ignore_changes = [
      configuration_store_id // required due to https://github.com/hashicorp/terraform-provider-azurerm/issues/24109
    ]
  }
}

Debug Output/Panic Output

No change in terraform plan detected & no change made by apply

Expected Behaviour

~ resource "azurerm_app_configuration_key" "setting" {
~ etag = "" -> (known after apply)
~ value = "testvalue2" -> ""
# (7 unchanged attributes hidden)
}

Actual Behaviour

The conjunction of changing the value to empty string with the workaround with ignore_changes mentioned in the linked bug causes the change to be ignored.

  • If the new value is not empty, the change is detected and applied as expected
  • If the key is completely new, it gets created and the value is set as expected
  • If the configuration_store_id is not ignored, the change is detected and applied as expected

We did not yet observe similar issues in some other circumstances, but it has already caused us a production issue because this unexpected behavior can easily go unnoticed when running terraform apply and we have no guarantee that this is the only way the issue can manifest.

Steps to Reproduce

  • Apply the terraform configuration snippet given with nonempty value
  • Change the value to empty string
  • Run terraform plan and see that it does not reveal any changes

Important Factoids

No response

References

#24109 (comment)

@tombuildsstuff
Copy link
Contributor

Notes whilst passing through/reviewing this one: looks like this field is marked as Computed when it shouldn't be.

Copy link

This functionality has been released in v3.89.0 of the Terraform Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

Copy link

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 26, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants