You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[WARN] Provider "provider[\"registry.terraform.io/hashicorp/azurerm\"].example" produced an unexpected new value for module.MODULENAME, but we are tolerating it because it is using the legacy plugin SDK.
The following problems may be the cause of any confusing errors from downstream operations:
- .cdn_frontdoor_origin_path: was cty.StringVal("/"), but now cty.StringVal("")
[TRACE] GRPCProvider: GetProviderSchema
[TRACE] GRPCProvider: returning cached schema: EXTRA_VALUE_AT_END=registry.terraform.io/hashicorp/azurerm
Next Plan
# module.MODULENAME will be updated in-place
~ resource "azurerm_cdn_frontdoor_route" "cdn_frontdoor_route" {
+ cdn_frontdoor_origin_path = "/"
...
Expected Behaviour
When cache settings are modified from Azure Portal UI this cdn_frontdoor_origin_path is not nulled after "Update". I would expect this to be case with Terraform modifications as well.
Actual Behaviour
Every time when some of the settings in cache { } block are changed or block is removed or added - Terraform applies this change, but ignores what is set in Terraform configuration code for argument cdn_frontdoor_origin_path and replaces it with a null value. The next apply tracks the configuration and re-adds value of cdn_frontdoor_origin_path which is reported in customer's plan/apply :
+ cdn_frontdoor_origin_path = "/"
This behavior is not happening when changing cache settings from Azure portal UI.
Steps to Reproduce
Please find attached example Terraform code to build infrastructure where you can add and remove the cache block to see the behavior described.
Important Factoids
If customer changes cache settings and does back-to-back apply runs, it will reset the value to match the configuration. Not ideal for a workaround.
References
No response
The text was updated successfully, but these errors were encountered:
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.
Is there an existing issue for this?
Community Note
Terraform Version
1.6.4
AzureRM Provider Version
3.81.0
Affected Resource(s)/Data Source(s)
resource azurerm_cdn_frontdoor_route
Terraform Configuration Files
Debug Output/Panic Output
Apply Time
Next Plan
Expected Behaviour
When cache settings are modified from Azure Portal UI this
cdn_frontdoor_origin_path
is not nulled after "Update". I would expect this to be case with Terraform modifications as well.Actual Behaviour
Every time when some of the settings in
cache { }
block are changed or block is removed or added - Terraform applies this change, but ignores what is set in Terraform configuration code for argumentcdn_frontdoor_origin_path
and replaces it with anull
value. The next apply tracks the configuration and re-adds value ofcdn_frontdoor_origin_path
which is reported in customer's plan/apply :+ cdn_frontdoor_origin_path = "/"
This behavior is not happening when changing cache settings from Azure portal UI.
Steps to Reproduce
Please find attached example Terraform code to build infrastructure where you can add and remove the
cache
block to see the behavior described.Important Factoids
If customer changes cache settings and does back-to-back apply runs, it will reset the value to match the configuration. Not ideal for a workaround.
References
No response
The text was updated successfully, but these errors were encountered: