Error: aws_autoscaling_group - Provider produced inconsistent final plan

[Aussie007]

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

v0.12.6

Affected Resource(s)

• aws_autoscaling_group

Expected Behavior

terraform apply should finish with no errors

Actual Behavior

Error: Provider produced inconsistent final plan

When expanding the plan for
module.eks_stack.aws_autoscaling_group.as_node_group to include new values
learned so far during apply, provider "aws" produced an invalid new value for
.availability_zones: was known, but now unknown.

This is a bug in the provider, which should be reported in the provider's own
issue tracker.

Steps to Reproduce

1. terraform apply

Important Factoids

This completes OK on running a second terraform apply

References

This issue was originally raised in the terraform GitHub, but then following an update of terraform, the error produced mentioned an issue with provider.
I was advised to then open an issue with the provider.
Ref:
hashicorp/terraform#21012

[santoshr1016]

This is the below error message I am getting after running the shell terraform apply

This is a bug in the provider, which should be reported in the provider's own
issue tracker.


Error: Provider produced inconsistent final plan

When expanding the plan for module.eks.aws_autoscaling_group.workers[0] to
include new values learned so far during apply, provider "aws" produced an
invalid new value for .initial_lifecycle_hook: planned set element
cty.ObjectVal(map[string]cty.Value{"default_result":cty.UnknownVal(cty.String),
"heartbeat_timeout":cty.UnknownVal(cty.Number),
"lifecycle_transition":cty.UnknownVal(cty.String),
"name":cty.UnknownVal(cty.String),
"notification_metadata":cty.UnknownVal(cty.String),
"notification_target_arn":cty.UnknownVal(cty.String),
"role_arn":cty.UnknownVal(cty.String)}) does not correlate with any element in
actual.

This is a bug in the provider, which should be reported in the provider's own
issue tracker.

Following versions I am using
Terraform v0.12.9

• provider.aws v2.30.0
• provider.local v1.4.0
• provider.null v2.1.2
• provider.random v2.2.1
• provider.template v2.1.2

[kiefersmith]

I am also running into this issue. Any guidance?

[bkero]

I'm running into this while applying a codebuild resource:

When expanding the plan for
module.kinesis_lambda.aws_codebuild_project.kinesis_lambda to include new
values learned so far during apply, provider "aws" produced an invalid new
value for .source: planned set element
cty.ObjectVal(map[string]cty.Value{"auth":cty.SetValEmpty(cty.Object(map[string]cty.Type{"resource":cty.String,
"type":cty.String})), "buildspec":cty.UnknownVal(cty.String),
"git_clone_depth":cty.NullVal(cty.Number),
"insecure_ssl":cty.NullVal(cty.Bool), "location":cty.StringVal(""),
"report_build_status":cty.NullVal(cty.Bool),
"type":cty.StringVal("CODEPIPELINE")}) does not correlate with any element in
actual.

From the following resource:

resource "aws_codebuild_project" "kinesis_lambda" {
  name          = "ads-kinesis-lambda-transformation-codebuild"
  build_timeout = "60"
  service_role = "${aws_iam_role.codebuild_role.arn}"
  artifacts {
    type = "CODEPIPELINE"
  }
  environment {
    compute_type    = "BUILD_GENERAL1_SMALL"
    image           = "aws/codebuild/standard:1.0"
    type            = "LINUX_CONTAINER"
    privileged_mode = true
  }
  logs_config {
    cloudwatch_logs {
      group_name  = "${aws_cloudwatch_log_group.kinesis_lambda_codebuild.name}"
      stream_name = "codebuild_logs"
    }
  }
  source {
    type      = "CODEPIPELINE"
    buildspec = "${data.template_file.kinesis_lambda_buildspec.rendered}"
  }
  tags = "${merge(map("Name","Kinesis Lambda CodeBuild Project" ), var.codepipeline_tags, var.custom_tags)}"
}

[solarmosaic-kflorence]

Looks very similar to #10615

Sometimes just running terraform apply again will work. But if it doesn't, as a workaround you can mark the resource as tainted with -taint and then run terraform apply again. This will force the resource to be re-created.

[anmonteiro]

This happened to me because I was using both availability_zones and vpc_zone_identifier in aws_autoscaling_group.

The documentation mentions:

availability_zones - (Required only for EC2-Classic) A list of one or more availability zones for the group. This parameter should not be specified when using vpc_zone_identifier.

The error is gone if I don't specify the two, but it took a little sleuthing to piece this together.

[brendan-sherrin]

I'm getting a similar error applying dynamic canonical ids aqquired from a list in an SSM Param to S3 buckets.

Error: Provider produced inconsistent final plan

When expanding the plan for
module.S3Configuration.aws_s3_bucket. to include new values
learned so far during apply, provider "registry.terraform.io/-/aws" produced
an invalid new value for .grant: actual set element
cty.ObjectVal(map[string]cty.Value{"id":cty.StringVal(""),
"permissions":cty.SetVal([]cty.Value{cty.StringVal("FULL_CONTROL")}),
"type":cty.StringVal("CanonicalUser"), "uri":cty.NullVal(cty.String)}) does
not correlate with any element in plan.

This is a bug in the provider, which should be reported in the provider's own
issue tracker.

I initially got the error using aws provider 2.53, upgraded to 2.56 and still occurs.

Edit - Was able to get it working 2 ways:

1. Tainted the S3's in question, worked on 2x that were empty
2. Hashed out the dynamic "grant" section for the canonical id ACL's on each bucket > apply, then unhashed again > apply, which worked. Issue may be with updating in place changing dynamic values, removing all or adding a brand new set looks to work fine.

The dynamic section on the S3 in question that was hashed out:

    dynamic "grant" {
    for_each = local.canonicallist
        content {
            id         = grant.value
            type       = "CanonicalUser"
            permissions = ["BLAH"]
        }
    }

[gblues]

I'm getting the same error in the same resource:

When expanding the plan for module.redacted.aws_autoscaling_group.workers["foo"] 
to include new values learned so far during apply, provider 
"registry.terraform.io/-/aws"  produced an invalid new value for .vpc_zone_identifier: 
planned set element cty.StringVal("subnet-redacted-12345") does not correlate 
with any element in actual.

• Terraform: 0.12.20
• AWS provider: 2.59.0
• we use a CI infrastructure that generates a plan and then tries to apply that plan. The error occurs during the apply attempt.
• we are not using availability_zones on the ASG (per anmonteiro's comment above)
• the plan is attempting to do an in-place update of the ASG (not a delete/recreate)
• when I deleted the above object from the state (and manually deleted the ASG in the AWS console), the same module applied successfully

[iancward]

I've seen this as well, but I think it's because I'm using a value from random_string in the tags; the random value isn't available until apply-time, at which point terraform freaks out that things have changed.
In fact, the list of tags during the plan shows that some items are (known after apply).

However, since Terraform knows that the values won't be known until they're available, it should proceed without throwing the warning.

Here's the actual output:

Error: Provider produced inconsistent final plan

When expanding the plan for module.example_asg.aws_autoscaling_group.app[0] to
include new values learned so far during apply, provider
"registry.terraform.io/-/aws" produced an invalid new value for .tags: length
changed from 6 to 8.

This is a bug in the provider, which should be reported in the provider's own
issue tracker.

This is the output of terraform -version:

Terraform v0.12.24
+ provider.aws v2.64.0
+ provider.random v2.2.1
+ provider.template v2.1.2

[buckyguy33]

I'm receiving the same error as posted above. Also using a value from random_string in the tags.

Error Output:

 Error: Provider produced inconsistent final plan

 When expanding the plan for
 module.example_asg.aws_autoscaling_group.instance_asg[0] to include
 new values learned so far during apply, provider "registry.terraform.io/-/aws"
 produced an invalid new value for .tags: length changed from 20 to 23.

 This is a bug in the provider, which should be reported in the provider's own
 issue tracker.

Versions used:

Terraform v0.12.26
AWS Provider 2.66.0
Random Provider 2.3.0
Template Provider 2.1.2

[fred97855]

This issue is still happening....

Terraform v0.13.1

• provider registry.terraform.io/hashicorp/archive v1.3.0
• provider registry.terraform.io/hashicorp/aws v3.3.0
• provider registry.terraform.io/hashicorp/local v1.4.0
• provider registry.terraform.io/hashicorp/null v2.1.2
• provider registry.terraform.io/hashicorp/time v0.5.0

values learned so far during apply, provider
"registry.terraform.io/hashicorp/null" changed the planned action from
CreateThenDelete to DeleteThenCreate.

[bflad]

@fred97855 for the changed the planned action from CreateThenDelete to DeleteThenCreate error, I believe this was fixed upstream in Terraform CLI by hashicorp/terraform#26192, which was released in Terraform 0.13.3. If you are still running into this same error after upgrading Terraform CLI itself, please open an issue upstream in https://github.com/hashicorp/terraform/issues since that particular error cannot be fixed in Terraform Providers (see referenced pull request for more details).

[ipleten]

I got this after I set 'default_tag' in provider and applied against EKS cluster.

When expanding the plan for
module.eks.module.node_groups.aws_eks_node_group.workers["common-nodes"] to
include new values learned so far during apply, provider
"registry.terraform.io/hashicorp/aws" produced an invalid new value for
.launch_template[0].version: was cty.StringVal("24"), but now
cty.StringVal("25").

next run showed:

    ~ launch_template {
            id      = "xxxx"
            name    = "yyyyy"
          ~ version = "24" -> "25"

[justinretzolk]

Hey y'all 👋 Thank you for taking the time to file this issue and for the continued discussion! Given that there's been a number of AWS provider releases since it was initially filed, can anyone confirm whether you're still experiencing this behavior?

[solarmosaic-kflorence]

@justinretzolk I have not seen this problem in quite some time. For the record, we are mostly on aws provider version 3.54+ and Terraform 1.0.0+ at this point.

[kiuby]

Hey, i can confirm we're still facing this issue :

│ Error: Provider produced inconsistent final plan
│
│ When expanding the plan for aws_autoscaling_group.workers_3a to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/aws" produced an
│ invalid new value for .tags: planned set element cty.MapValEmpty(cty.String) does not correlate with any element in actual.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

Another kind of error that we're facing:

│ Error: Provider produced inconsistent final plan
│
│ When expanding the plan for aws_autoscaling_group.workers_3a to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/aws" produced an
│ invalid new value for .tags: length changed from 10 to 11.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

These errors are only happening when we're creating an aws_eks_cluster (which takes roughly 13min), an aws_launch_template and the aws_autoscaling_group on the same run. (3 resources)

Once the EKS cluster is created (and the failure of the apply), we can relaunch a terraform apply and create the launch template and the autoscaling group without any issues.
Maybe related to something computed at the beginning of the run that is updated later on?

By the way : we're using the latest version of the provider ("3.69.0") and terraform version 1.1.0

[matt-mercer]

Hi ... seeing what looks like the same issue creating a DDB stream / aws_lambda_event_source_mapping

Error: Provider produced inconsistent final plan When expanding the plan for to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/aws" produced an invalid new value for .event_source_arn: was cty.StringVal(""), but now│ cty.StringVal("arn:aws:dynamodb:xxxx:xxx:table/xxxxx/stream/2022-03-31T12:51:18.727").

repeat apply and it works the second time

[lahirushanaka]

I also receiving similar error when deploying ALB and S3 as log bucket. when run it again this will not happend.

Error: Provider produced inconsistent final plan │ │ When expanding the plan for module.alb.aws_lb.this[0] to include new values learned so far during apply, provider │ "registry.terraform.io/hashicorp/aws" produced an invalid new value for .access_logs[0].bucket: was cty.StringVal(""), but now │ cty.StringVal("dev-alb-accesslog-s3"). │ │ This is a bug in the provider, which should be reported in the provider's own issue tracker.

AWS Provide version - 4.24.0

[byronliucareer]

i also got an error when create iam policy for ec2 role.

Error: Provider produced inconsistent final plan when expanding the plan for aws_iam_policy.this[xx] to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/aws" produced an invalid new value for policy: was cty.StringVal(xx), but now cty.StringVal(xx). This is a bug in the provider, which should be reported in the provider's own issue tracker. It was good when ran terraform from local machine but the error occurred when deployed via bamboo pipeline.

Any advice will be much appreciated.

Versions on my local machine:
Terraform v1.2.5
AWS v4.29.0

[jar-b]

Hi @Aussie007 - After attempting a reproduction based on part of your original configuration, I believe this may have been caused by both availability_zones and vpc_zone_identifier attributes being set.

Logic was added to properly detect this conflict at plan time in #12927 (v3.0.0), which means the original configuration can't be applied at all:

$ terraform plan
data.aws_availability_zones.available: Reading...
data.aws_ami.amzn-ami-minimal-hvm-ebs: Reading...
data.aws_availability_zones.available: Read complete after 0s [id=us-west-2]
data.aws_ami.amzn-ami-minimal-hvm-ebs: Read complete after 0s [id=ami-080838fe2601dc7f2]
╷
│ Error: Conflicting configuration arguments
│
│   with aws_autoscaling_group.example,
│   on main.tf line 51, in resource "aws_autoscaling_group" "example":
│   51:   availability_zones        = [data.aws_availability_zones.available.names[0], data.aws_availability_zones.available.names[1], data.aws_availability_zones.available.names[2]]
│
│ "availability_zones": conflicts with vpc_zone_identifier

Show Terraform Configuration

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
  }
}

provider "aws" {}

data "aws_availability_zones" "available" {}

data "aws_ami" "amzn-ami-minimal-hvm-ebs" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["amzn-ami-minimal-hvm-*"]
  }

  filter {
    name   = "root-device-type"
    values = ["ebs"]
  }
}

resource "aws_vpc" "example" {
  cidr_block = "10.1.0.0/16"
}

resource "aws_subnet" "example1" {
  vpc_id     = aws_vpc.example.id
  cidr_block = "10.1.1.0/24"
}

resource "aws_subnet" "example2" {
  vpc_id     = aws_vpc.example.id
  cidr_block = "10.1.2.0/24"
}

resource "aws_launch_configuration" "example" {
  name          = "jb-test"
  image_id      = data.aws_ami.amzn-ami-minimal-hvm-ebs.id
  instance_type = "t2.micro"
}

resource "aws_autoscaling_group" "example" {
  name_prefix               = "jb-test"
  availability_zones        = [data.aws_availability_zones.available.names[0], data.aws_availability_zones.available.names[1], data.aws_availability_zones.available.names[2]]
  desired_capacity          = 1
  max_size                  = 1
  min_size                  = 1
  health_check_type         = "EC2"
  health_check_grace_period = 0
  vpc_zone_identifier       = [aws_subnet.example1.id, aws_subnet.example2.id]

  launch_configuration = aws_launch_configuration.example.id

  lifecycle {
    create_before_destroy = true
  }
}

I'll leave this open for now to allow time for a response to the reproduction. However, in the absence of an ongoing issue with the availability_zones attribute in the latest provider version, I'm proposing this be closed via #12927.

[jar-b]

For those who have separately commented with "inconsistent final plan" errors (this is an error that can happen with any resource), we'd ask that you please open a new issue with a complete configuration and relevant logs. This will allow us to keep the discussion in this issue limited to the aws_autoscaling_group availability_zones attribute, and provide the proper amount of context for maintainers to reproduce errors with other resources. Thanks!

[jar-b]

With no confirmation of ongoing issues, this will be closed via #12927.

As mentioned in the previous comment - for those with "inconsistent final plan" errors on attributes other than aws_autoscaling_group.availability_zones, please open a new issue. Thanks!

[github-actions]

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.