State 'loses' resources?

[ghost]

This issue was originally opened by @huseyinham as hashicorp/terraform#18646. It was migrated here as a result of the provider split. The original body of the issue is below.

---

Hi! I'm not sure if this should go to core or AWS-provider but I seem to be having an issue where terraform 'loses' state when applying and destroying fairly large amounts of listener rules over a short period of time (but over different applies in parallel)?

One apply contains 6 listener rules being created, so all-in-all I'm probably creating around 180 listener rules. I originally had less terraform runs because I bundled listener rule creation into the same file as target groups, but when I ran into this issue I thought it may be a race condition of some kind during the destruct so split them out, however it still occurs.

Terraform Version

v0.11.0

Terraform Configuration Files

I'm using modules that utilise these resources:

resource "aws_lb_listener_rule" "scope" {
  count        = "${var.count            }"
  listener_arn = "${var.http_listener_arn}"
  priority     = "${var.rule_priority    }"

  action {
    type             = "forward"
    target_group_arn = "${data.aws_lb_target_group.tg.arn}"
  }

  condition {
    field  =   "host-header"
    values = [ ... ]
  }
}

resource "aws_lb_listener_rule" "https" {
  count        = "${var.count             }"
  listener_arn = "${var.https_listener_arn}"
  priority     = "${var.rule_priority     }"

  action {
    type             = "forward"
    target_group_arn = "${data.aws_lb_target_group.tg.arn}"
  }

  condition {
    field  =   "host-header"
    values = [ ... ]
  }
}

Example 1

Creation of 2 listener rules:

14:43:58 module.balancer_app_cc_route.aws_lb_listener_rule.scope: Creating...
14:43:58 module.balancer_app_cc_route.aws_lb_listener_rule.scope: Creation complete after 0s (ID: arn:aws:elasticloadbalancing:eu-west-1:...adc8fc0412ca8ca3)
14:43:58 module.balancer_cc_route.aws_lb_listener_rule.scope: Creating...
14:43:58 module.balancer_cc_route.aws_lb_listener_rule.scope: Creation complete after 0s

Destruction of 1 listener rule only(?):

14:48:56 module.balancer_app_cc_route.aws_lb_listener_rule.scope: Destroying... (ID: arn:aws:elasticloadbalancing:eu-west-1:...adc8fc0412ca8ca3)
14:48:56 module.balancer_app_cc_route.aws_lb_listener_rule.scope: Destruction complete after 1s

Example 2

14:36:22 module.balancer_cc_route.aws_lb_listener_rule.scope: Creating...
14:36:22 module.balancer_app_cc_route.aws_lb_listener_rule.scope: Creating...
14:36:23 module.balancer_cc_route.aws_lb_listener_rule.scope: Creation complete after 0s (ID: arn:aws:elasticloadbalancing:eu-west-1:...b43aac1d4ffdbd72)
14:36:23 module.balancer_app_cc_route.aws_lb_listener_rule.scope: Creation complete after 0s

14:59:43 module.balancer_cc_route.aws_lb_listener_rule.scope: Destroying... (ID: arn:aws:elasticloadbalancing:eu-west-1:...b43aac1d4ffdbd72)
14:59:43 module.balancer_cc_route.aws_lb_listener_rule.scope: Destruction complete after 0s

Expected Behavior

The listeners created via an apply are destroyed when a destruct is run.

Actual Behavior

Some of the listener_rules are 'lost' and therefore doesn't destroy them (although terraform claims they were). Then when I try to destroy the Target Groups (via a different terraform destroy run), it can't due to it still being attached to a listener rule.

I noticed that during creation, the problematic listener rule never gives an arn ID after when it states 'Creation Complete'.

I'm not really sure how to proceed to debug from here though I'm afraid so any support or highlighting my stupidity is appreciated.

[bflad]

The fix for this has been merged (#6154) and will release with version 1.41.0 of the AWS provider, likely middle of this week. 👍

[bflad]

This has been released in version 1.41.0 of the AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

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