Please vote on this issue by adding a :thumbsup: reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave comments along the lines of "+1", "me too" or "any updates", 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.4.6
AzureRM Provider Version
3.116.0
Affected Resource(s)/Data Source(s)
data.azurerm_subnet,data.azurerm_client_config
Terraform Configuration Files
It's extremely basic usage of both of these resources:
data "azurerm_client_config" "current" {}
resource "mongodbatlas_network_peering" "azure" {
project_id = mongodbatlas_project.azure.id
container_id = mongodbatlas_network_container.azure.container_id
provider_name = local.atlas_cloud_provider
azure_directory_id = data.azurerm_client_config.current.tenant_id
azure_subscription_id = data.azurerm_client_config.current.subscription_id
resource_group_name = var.resource_group_name
vnet_name = var.virtual_network_name
}
### Debug Output/Panic Output
```shell
Nothing interesting. I've walked it in the debugger and everything works fine. It's just that the for some reason the existing state isn't referenced/loaded (I think).
Expected Behaviour
When we run plans subsequent times the data source should not trigger recreation for downstream resources.
Actual Behaviour
Any resource that references the data source is forced into a change. As you can see it causes some fairly serious resources to change.
I've noticed you all do some interesting things that I could conceive of as causing this sort of unexpected behavior, but I haven't found direct proof. Specifically I think this might have to do with the fact that you all have made a vendored shim of the pluginsdk.
# (depends on a resource or a module with changes pending)
# there is no dependency here. It's just empty.
<= data "azurerm_client_config" "current" {
+ client_id = (known after apply)
+ id = (known after apply)
+ object_id = (known after apply)
+ subscription_id = (known after apply)
+ tenant_id = (known after apply)
}
# module.atlas_projects["X"].mongodbatlas_network_peering.azure must be replaced
-/+ resource "mongodbatlas_network_peering" "azure" {
+ accepter_region_name = (known after apply)
~ atlas_cidr_block = "192.168.X.0/22" -> (known after apply)
+ atlas_gcp_project_id = (known after apply)
~ atlas_id = "XXXXXX" -> (known after apply)
+ atlas_vpc_name = (known after apply)
+ aws_account_id = (known after apply)
~ azure_directory_id = "XXXXXXX" # forces replacement -> (known after apply) # forces replacement
~ azure_subscription_id = "XXXXXXX" # forces replacement -> (known after apply) # forces replacement
+ connection_id = (known after apply)
+ error_message = (known after apply)
+ error_state = (known after apply)
+ error_state_name = (known after apply)
+ gcp_project_id = (known after apply)
~ id = "XXXXXXXX" -> (known after apply)
+ network_name = (known after apply)
~ peer_id = "XXXXXXXX" -> (known after apply)
+ route_table_cidr_block = (known after apply)
~ status = "AVAILABLE" -> (known after apply)
+ status_name = (known after apply)
+ vpc_id = (known after apply)
# (5 unchanged attributes hidden)
}
Steps to Reproduce
No response
Important Factoids
If you can point me to some useful code points I can use the debugger to explore more.
Is there an existing issue for this?
Community Note
Terraform Version
1.4.6
AzureRM Provider Version
3.116.0
Affected Resource(s)/Data Source(s)
data.azurerm_subnet,data.azurerm_client_config
Terraform Configuration Files
Expected Behaviour
When we run plans subsequent times the data source should not trigger recreation for downstream resources.
Actual Behaviour
Any resource that references the data source is forced into a change. As you can see it causes some fairly serious resources to change.
I've noticed you all do some interesting things that I could conceive of as causing this sort of unexpected behavior, but I haven't found direct proof. Specifically I think this might have to do with the fact that you all have made a vendored shim of the
pluginsdk
.Steps to Reproduce
No response
Important Factoids
If you can point me to some useful code points I can use the debugger to explore more.
References
https://github.com/hashicorp/terraform-provider-azurerm/issues/20303 https://github.com/hashicorp/terraform/issues/29716 https://discuss.hashicorp.com/t/data-sources-forcing-replacement-even-though-nothing-has-changed/46452/2