Terraform-provider-aws: aws_lb_target_group health_check.0.matcher no longer defaults to 200

[devshorts]

The LB target group health check matcher default value has changed from versions 1.2 of aws provider to 1.3.0 of the aws provider.

Terraform Version

0.10.7

Affected Resource(s)

Please list the resources as a list, for example:

• aws_lb_target_group

resource "aws_alb_target_group" "curalate_alb_target_group" {
  name     = "${var.name}"
  port     = "${var.target_group_port}"
  protocol = "${var.target_group_protocol}"
  vpc_id   = "${var.vpc_id}"

  health_check {
    healthy_threshold   = "${var.healthy_threshold}"
    unhealthy_threshold = "${var.unhealthy_threshold}"
    timeout             = "${var.health_check_timeout}"
    path                = "${var.health_check_path}"
    interval            = "${var.health_check_interval}"
  }

  tags = "${merge(var.extra_tags, map("Terraform", "true", "Name", var.name))}"
}

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Debug Output

  ~ module.taxonomy-service.module.curalate_ecs_service_alb.aws_alb_target_group.curalate_alb_target_group
      health_check.0.matcher:                     "200" => ""

Expected Behavior

An unset health checker shoulder set the matcher codes to 200 per the documentation

Actual Behavior

AWS Provider 1.2 worked fine. With aws provider 1.3.0 the matcher is no set to an empty string and this is invalid

11:28:57 * module.taxonomy-service.module.curalate_ecs_service_alb.aws_alb_target_group.curalate_alb_target_group: 1 error(s) occurred:
11:28:57 
11:28:57 * aws_alb_target_group.curalate_alb_target_group: Error modifying Target Group: ValidationError: Health check matcher HTTP code cannot be empty
11:28:57    status code: 400, request id: 639f20ca-cb04-11e7-910d-fbedb2576999
11:28:57 
11:28:57 Terraform does not automatically rollback in the face of errors.
11:28:57 Instead, your Terraform state file has been partially updated with
11:28:57 any resources that successfully completed. Please address the error
11:28:57 above and apply again to incrementally change your infrastructure.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply

[dabdine-r7]

Just encountered the same issue!

[devshorts]

@dabdine-r7 yeah, super sudden. We worked around it by supplying the matcher in our module, but kind of a nasty surprise to have all of our deployments fail

[tfhartmann]

this affected us on terraform 0.10.8 as well, FWIW.

[hSATAC]

Got this too.
Also other health check default values...

[radeksimko]

Hi folks,
sorry for the troubles.

The default value was intentionally removed to support TCP-based target groups where matcher is irrelevant. I was under the impression that this change shouldn't cause problems for existing deployments, but I was clearly wrong.

btw. it is mentioned in https://github.com/terraform-providers/terraform-provider-aws/blob/master/CHANGELOG.md#130-november-16-2017

I'm not sure if it's worth adding migration at this point - @catsby what do you think?

[AnishAnil]

+1 Hitting the same error

---

1 error(s) occurred:

• aws_lb_target_group.test: 1 error(s) occurred:

• aws_lb_target_group.test: Error modifying Target Group: ValidationError: Health check matcher HTTP code cannot b
  e empty
  status code: 400, request id: d1321a9a-cd57-11e7-86d8-055e5a3fa73d

---

Is there a quick WorkAround for this one.

Critical Blocker

[catsby]

The quick work around is to add a matcher value in your configuration. The default value is 200, so that's probably a good value to use for now unless you're aware of specific needs to adjust it

[shorn]

I really dislike having my infrastructure just break randomly on me like this.
What's the right way to fix the AWS provider in place so it's not sliding around underneath me?

Is it just:

provider "aws" {
  version = "1.3"
}

?

And is https://github.com/terraform-providers/terraform-provider-aws/blob/master/CHANGELOG.md the right place to keep an eye on when looking at upgrades?

[Ninir]

Hi @shorn Yes, you're right for both of your questions.

Locking is always a good idea to avoid such slidings, and allows you to control your changes over upgrades, so that you can plan a migration based on the Changelog and potential breaking changes.

As @catsby exposed it, adding the 200 matcher value is the necessary step here.

This Load Balancer work was a pretty huge one, so we're sorry if any issue have been encountered.

[marcosdiez]

Another solution for the problem is to use an old version of the AWS module.
This one works:

provider "aws" {
  version = "1.1"
  region = "us-east-1" # the advantage of the region being hardcoded is that it makes terraform import works as expected
}

[catsby]

I've opened a PR to address this in #2380

[danstepanov]

@Ninir @catsby Would this be the right way to specify a default of 200?

variable "healthcheck" {
  description = "Path to a healthcheck endpoint"
  default     = 200
}

I'm not sure what a "matcher" is

[minac]

@danstepanov Something like this inside your aws_alb_target_group resource:

health_check {
    path     = "/"
    protocol = "HTTPS"
    matcher  = "200"
  }

I hope this helps.

[bflad]

Hi folks 👋 I'm not sure why this really old issue is still open as it appears to have been resolved awhile ago, but if you are still experiencing an issue please open a new GitHub issue filling out the issue details. Thanks so much.

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