aws_lb_target_group for an instance type target group is trying to add (or make a change) of attribute: lambda_multi_value_headers_enabled

[darkwizard242]

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 v0.11.13

Affected Resource(s)

• aws_alb_target_group
• aws_alb_listener_rule

Terraform Configuration Files

resource "aws_alb_target_group" "myapp-dev-target-group" {
  name     = "myapp-dev-tg"
  port     = 443
  protocol = "HTTPS"
  vpc_id   = "${aws_vpc.myvpc.id}"
  health_check {
    interval            = 30
    path                = "/myapp"
    protocol            = "HTTPS"
    port                = 443
    timeout             = 5
    healthy_threshold   = 5
    unhealthy_threshold = 2
    matcher             = "200,302"
  }
  tags {
    Name        = "dev-target-group"
    Owner       = "Tech-Overlord"
    Environment = "dev"
  }
}

Expected Behavior

The code provided above is just a sample for an existing instance type target group in AWS that already has been created using Terraform and should not reflect in either terraform plan or terraform apply .

Actual Behavior

Although the terraform resource for the target group above is instance type and it already exists. It suggests the following change every time that I try to do a terraform plan or terraform apply:

lambda_multi_value_headers_enabled: "" => "false"

It is understandable if it suggests for this attribute change if the target group was of lambda type. However, a prompt for the change doesn't make sense if the target group is not of lambda type. I would recommend that the attribute change should only be prompted when the target group type is lambda. However, if that is not the case and there is a reason behind that attribute change to be supplied against an instance type target group, then please advise.

Steps to Reproduce

Either of the following against an existing instance type target group:

1. terraform plan
2. terraform apply

Temporary workaround

Adding a lifecycle block with ignore_changes for lambda_multi_value_headers_enabled in the aws_alb_target_group resource for an instance type target group will stop prompting for the change when terraform plan or terraform apply are executed.

lifecycle {
   ignore_changes = "lambda_multi_value_headers_enabled"
 }

References

Listed below are the original feature request that was raised and the pull request that included this new change for lambda_multi_value_headers_enabled:

• Original feature request
• Original pull request

[darkwizard242]

This bug no longer persists in AWS provider version: v2.20.0 with Terraform (0.12.x).

Tested on:

Terraform v0.12.3
provider.aws v2.20.0

[Sytten]

It is still present here:

Terraform v0.11.3
provider.aws v2.27.0

[darkwizard242]

@Sytten - You may want to try out the lifecycle workaround:

lifecycle {
   ignore_changes = "lambda_multi_value_headers_enabled"
 }

[Sytten]

Yeah thats what I did, still I didnt have this problem before so its a regression

[zliuva]

I'm seeing the same issue and also with deregistration_delay and slow_start (i.e. any field that was not explicitly set)

# terraform version
Terraform v0.12.15
+ provider.aws v2.37.0

[kladiv]

+1

[mrnonz]

It is still occur here:

Terraform v0.11.14
+ provider.aws v2.57.0

[bcsgh]

I'm seeing this (and also proxy_protocol_v2=false) with:

Terraform v0.13.4
+ provider registry.terraform.io/hashicorp/aws v3.23.0

Also lifecycle.ignore_changes seems to not work here (?), presumably because the is being updated from rather than "".

[zhelding]

This issue seems to have been resolved in more up-to-date versions of Terraform; if the problem persists, please feel free to open a new issue!

[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.