Error: Provider produced inconsistent result after apply

[elcaos]

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

Terraform Version

terraform version 0.12.6
provider "aws" (hashicorp/aws) 2.26.0

Affected Resource(s)

• aws_ecr_lifecycle_policy

Terraform Configuration Files

resource "aws_ecr_repository" "buildmon-image-registry" {
  name = local.buildmon_base_image
  tags = local.default_tags
}

resource "aws_ecr_lifecycle_policy" "buildmon-lifecycle-policy" {
  repository = aws_ecr_repository.buildmon-image-registry.name

  policy = <<EOF
{
    "rules": [
        {
            "rulePriority": 1,
            "description": "Keep last 2 images",
            "selection": {
                "tagStatus": "any",
                "countType": "imageCountMoreThan",
                "countNumber": 2
            },
            "action": {
                "type": "expire"
            }
        }
    ]
}
EOF

}

Debug Output

• terraform apply ././tfplan/buildmon_20190904-154608.tfplan
  aws_ecr_lifecycle_policy.pipeline_ecr-lifecycle-policy: Destroying... [id=buildmon]
  aws_ecr_lifecycle_policy.buildmon-lifecycle-policy: Creating...
  aws_ecr_lifecycle_policy.pipeline_ecr-lifecycle-policy: Destruction complete after 0s
  Error: Provider produced inconsistent result after apply

When applying changes to aws_ecr_lifecycle_policy.buildmon-lifecycle-policy,
provider "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.

Expected Behavior

changed internal name of TF resource. Expected to destroy old resource and create a new one.

Actual Behavior

provider returned error

Steps to Reproduce

1. create policy
2. apply terraform
3. change terraform resource name
4. apply terraform again

• #0000

[timbaileyjones]

I am getting the same error, but after deploying (update, actually) a different resource type: API gateway deployment.

[glerma]

I also got this error when applying the below:

When applying changes to
aws_vpc_endpoint_route_table_association.private_dynamodb[0], provider
"registry.terraform.io/-/aws" produced an unexpected new value for was
present, but now absent.

[andjelx]

We are facing similar rinning following:
module.vpc.aws_network_acl_rule.public_inbound[1]

terraform-aws-modules/vpc/aws 2.21.0
provider "aws" (hashicorp/aws) 2.43.0

[ghost]

I can see very similar.
Terraform v0.12.19
provider.aws v2.45.0

  # module.ecs_cluster_path.aws_iam_role_policy_attachment.ecs-SSMpolicy-attach will be created

  + resource "aws_iam_role_policy_attachment" "ecs-SSMpolicy-attach" {
      + id         = (known after apply)
      + policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonEC2RoleForSSM"
      + role       = "path-perms-role"
    }

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

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

  Enter a value: yes

module.ecs_cluster_path.aws_iam_role_policy_attachment.ecs-SSMpolicy-attach: Creating...

Error: Provider produced inconsistent result after apply

When applying changes to
module.ecs_cluster_path.aws_iam_role_policy_attachment.ecs-SSMpolicy-attach,
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.

Interestingly the policy IS attached after the apply, but not registered in the state.
So next run TF will try and fail to attach it again.

[ghost]

Can this be fixed by deleting the state file?

[fatbasstard]

Hitting this error when renaming the aws_ecr_lifecycle_policy resource

[kgrech]

I see the same problem randomly when creating the AWS cloud watch rule:

Error: Provider produced inconsistent result after apply

When applying changes to aws_cloudwatch_event_rule.disable_environment_rule, 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.

It is usually fixed just by the simple retry

[queglay]

I've been seeing this a lot more recently, but don't recall it being an issue.

3774 [23:29:14] module.node.null_resource.install_deadline_worker[0]: Creation complete after 7m14s [id=6745026440273377723]
3775 [23:29:14] 
3776 [23:29:14] Error: timeout - last error: ssh: rejected: connect failed (Connection timed out)
3777 [23:29:14] 
3778 [23:29:14] 
3779 [23:29:14] 
3780 [23:29:14] Error: Provider produced inconsistent result after apply
3781 [23:29:14] 
3782 [23:29:14] When applying changes to
3783 [23:29:14] module.softnas.aws_network_interface_sg_attachment.sg_attachment_vpn[0],
3784 [23:29:14] provider "registry.terraform.io/-/aws" produced an unexpected new value for
3785 [23:29:14] was present, but now absent.
3786 [23:29:14] 
3787 [23:29:14] This is a bug in the provider, which should be reported in the provider's own
3788 [23:29:14] issue tracker.
3789 [23:29:14] 
3790 [23:29:14] ++ err_report 335 'terraform apply -lock=false --auto-approve'
3791 [23:29:14] ++ local lineno=335
3792 [23:29:14] ++ local 'msg=terraform apply -lock=false --auto-approve'

[madpipeline]

#17509 which gives the same error, but is easily solvable.

[ghost]

This has been released in version 3.36.0 of the Terraform AWS 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 for triage. Thanks!

[ghost]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!