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 other comments that do not add relevant new information or questions, 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
Terraform CLI and Terraform AWS Provider Version
Initializing provider plugins...
- Checking for available provider plugins...
- Downloading plugin for provider "random" (hashicorp/random) 2.3.0...
- Downloading plugin for provider "aws" (hashicorp/aws) 2.70.0...
- Downloading plugin for provider "external" (hashicorp/external) 1.2.0...
- Downloading plugin for provider "null" (hashicorp/null) 2.1.2...
Affected Resource(s)
- aws_appmesh_virtual_service
Terraform Configuration Files
resource "aws_appmesh_virtual_service" "vs" {
mesh_name = var.appmesh.name
name = "${local.name}.${var.service_discovery.namespace_name}"
spec {
provider {
virtual_router {
virtual_router_name = aws_appmesh_virtual_router.vr.name
}
}
}
}Debug Output
On first run, terraform fails like this:
Error: Provider produced inconsistent result after apply
When applying changes to
module.[MASKED].module.template.aws_appmesh_virtual_service.vs,
provider "registry.terraform.io/-/aws" produced an unexpected new value for
was present, but now absent.
This is a bug in the provider, which should be reported in the provider's own
issue tracker.
Then on retry, it fails like this:
Error: error creating App Mesh virtual service: ConflictException: VirtualService with name dev-i270-sst-template.dev-i270.[MASKED].local already exists with different clientRequestToken C1833BA9-42A4-48D3-B855-243582FC4B62
on .terraform/modules/[MASKED].template/terraform/modules/ecs/service_blue_green/appmesh.tf line 105, in resource "aws_appmesh_virtual_service" "vs":
105: resource "aws_appmesh_virtual_service" "vs" {
It appears as if terraform (and AWS) create the resource properly, but terraform fails to acknowledge the fact and does not reflect that fact the statefile. Then, another run of terraform apply does not see that resource in the statefile, and tries to create it again - failing, because it already exists.
Panic Output
Expected Behavior
The resources should've been created and terraform should not fail.
Actual Behavior
Terraform fails (ther first time) because of what it says is a bug in the provider. Then if fails the second time because the resources actually gets created but it's not reflected in the state file.
Steps to Reproduce
terraform apply
Important Factoids
The error appears randomly. We're frequently creating and destroying resources as part of out CICD pipeline (entire dev environments live for just a few days and are destroyed together with git branches being merged) and this happens once or twice a month with no distinguishable pattern. Therefore, we have not been able to reproduce this issue with debug logging enabled and only have the logs as attached.
Community Note
Terraform CLI and Terraform AWS Provider Version
Affected Resource(s)
Terraform Configuration Files
Debug Output
On first run, terraform fails like this:
Then on retry, it fails like this:
It appears as if terraform (and AWS) create the resource properly, but terraform fails to acknowledge the fact and does not reflect that fact the statefile. Then, another run of
terraform applydoes not see that resource in the statefile, and tries to create it again - failing, because it already exists.Panic Output
Expected Behavior
The resources should've been created and terraform should not fail.
Actual Behavior
Terraform fails (ther first time) because of what it says is a bug in the provider. Then if fails the second time because the resources actually gets created but it's not reflected in the state file.
Steps to Reproduce
terraform applyImportant Factoids
The error appears randomly. We're frequently creating and destroying resources as part of out CICD pipeline (entire dev environments live for just a few days and are destroyed together with git branches being merged) and this happens once or twice a month with no distinguishable pattern. Therefore, we have not been able to reproduce this issue with debug logging enabled and only have the logs as attached.