Terraform-provider-aws: Error: Only one of field, host_header, http_header, http_request_method, path_pattern, query_string or source_ip can be set in a condition block

[tomaszdudek7]

I think after merging https://github.com/terraform-providers/terraform-provider-aws/pull/8268 existing (now deprecated) condition blocks are broken.

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 Version

Terraform v0.12.18
+ provider.aws v2.42.0

Affected Resource(s)

• aws_alb_listener_rule

Terraform Configuration Files

resource "aws_alb_listener_rule" "infrastructure_version_info" {
  listener_arn = "..."
  condition {
    field  = "path-pattern"
    values = ["/infrastructure-version"]
  }
  action {
    type = "fixed-response"

    fixed_response {
      content_type = "text/html"
      message_body = "blah blah version 1"
      status_code  = "200"
    }
  }
  priority = 2
}

Expected Behavior

When message_body is edited and thus we try to apply following plan:

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # aws_alb_listener_rule.infrastructure_version_info will be updated in-place
  ~ resource "aws_alb_listener_rule" "infrastructure_version_info" {
        arn          = "arn:aws:xxxxx"
        id           = "arn:aws:xxxxxx"
        listener_arn = "arn:xxxxxx"
        priority     = 2

      ~ action {
            order = 1
            type  = "fixed-response"

          ~ fixed_response {
                content_type = "text/html"
              ~ message_body = "blah blah version 1" -> "blah blah version 2"
                status_code  = "200"
            }
        }

        condition {
            field  = "path-pattern"
            values = [
                "/infrastructure-version",
            ]

            path_pattern {
                values = [
                    "/infrastructure-version",
                ]
            }
        }
    }

we should update the listener rule correctly.

Actual behavior

An error occurs:

Error: Only one of field, host_header, http_header, http_request_method, path_pattern, query_string or source_ip can be set in a condition block

Additional information

Changing to not-deprecated version:

  condition {
    path_pattern {
      values = ["/infrastructure-version"]
    }
  }

does not help.

[borrell]

I don't think it's just the old syntax that's broken - I'm getting the same error on a rule that has the following condition blocks outlined:

condition {
  path_pattern {
    values = ["/examplepath"]
  }
}

condition {
  http_header {
    http_header_name = "x-example-name"
    values           = ["somevalue*"]
  }
}

Error: Only one of field, host_header, http_header, http_request_method, path_pattern, query_string or source_ip can be set in a condition block

[KiNgMaR]

Running into the same thing, I was able to reproduce using the following steps:

1) create rule like this:

resource "aws_lb_listener_rule" "..." {
  condition {
    path_pattern {
      values = [
        "/a",
      ]
    }
  }

  condition {
    host_header {
      values = ["example.com"]
    }
  }
}

1. then add another path to the list:

  condition {
    path_pattern {
      values = [
        "/a",
        "/b", # this is new
      ]
    }
  }

1. terraform apply and run into the error mentioned.

Basically it looks like making any changes to an already applied resource aws_lb_listener_rule with more than one condition causes it.

Workaround: terraform destroy -target=... && terraform apply (warning: will cause rules to be unavailable while apply is making the plan)

[borrell]

Oh good pickup @KiNgMaR - in the example I posted, I was making two updates to the resource

• updating the old syntax for path_pattern to the new syntax, and
• adding a second condition (http_header)

It appears that perhaps the conflict is coming from trying to add the 'new-syntax' path_pattern rule before removing the 'old-syntax' rule.

Tainting the resource (or manually removing the rule) before deploying resolves this issue, but it would be better if it could happen without intervention!

[russfcox]

Looks like a regression, it's not possible to update aws_lb_listener_rule resources in place, tainting works but that's not really a solution.

State file contents show both old and new condition formats on newly created rules with provider.aws v2.42.0 (This PR https://github.com/terraform-providers/terraform-provider-aws/pull/8268/files)

# aws_lb_listener_rule.host_name_routing:
resource "aws_lb_listener_rule" "host_name_routing" {
    arn          = "arn:aws:elasticloadbalancing:xx"
    id           = "arn:aws:elasticloadbalancing:xx"
    listener_arn = "arn:aws:elasticloadbalancing:xx"
    priority     = 10

    action {
        order            = 1
        target_group_arn = "arn:aws:elasticloadbalancing:xx"
        type             = "forward"
    }

    condition {
        field  = "host-header"
        values = [
            "my.hostname",
        ]

        host_header {
            values = [
                "my.hostname",
            ]
        }
    }
}

Where I only have the following defined in my terraform resource

resource "aws_lb_listener_rule" "host_name_routing" {
  listener_arn = aws_lb_listener.xx.arn
  priority     = 10
  action {
    type             = "forward"
    target_group_arn = local.live_target_group_arn
  }
  condition {
    host_header {
      values = [local.cf_alias]
    }
  }
}

[dpiddockcmp]

Damn. Sorry. The test suite doesn't have a test for performing in-place updates so this was missed.

It's a feature of the backwards compatibility in both the module and AWS API. The API returns the field and values in both places in the API for the two old field types. Which then the terraform stores. When doing an update, terraform provides all the existing state merged with changes as that makes sense for "computed" values. Otherwise a lot of things wouldn't work. Except here it triggers the error code

[emmm-dee]

Also hitting this bug when making changes to existing resources. Same versions as the report.
Can confirm tainting can be used as a workaround.

[vishwakumba]

We have a listener(ALB) with context paths and target groups in our terraform code, attaching existing target groups to new context paths or changing the order of the existing context path listener rules for the attached target groups in the code seems to produce this error for us.(since 13.12.19).

• Terraform v0.12.13 and provider.aws v2.42.0

The workaround we used was to use terraform aws provider version 2.41.0

[bflad]

The fix for this issue has been merged and will release with version 2.43.0 of the Terraform AWS Provider, later today. Thanks to @dpiddockcmp for the help fixing this. 👍

[hashibot[bot]]

This has been released in version 2.43.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!

[hashibot[bot]]

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!