Tearing down and re-applying a Gamelift Flexmatch matchmaking configuration does not properly refresh its ruleset

[FairlySadPanda]

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
• The resources and data sources in this provider are generated from the CloudFormation schema, so they can only support the actions that the underlying schema supports. For this reason submitted bugs should be limited to defects in the generation and runtime code of the provider. Customizing behavior of the resource, or noting a gap in behavior are not valid bugs and should be submitted as enhancements to AWS via the CloudFormation Open Coverage Roadmap.

Terraform CLI and Terraform AWS Cloud Control Provider Version

Terraform v1.10.5
on linux_amd64
+ provider registry.terraform.io/hashicorp/archive v2.2.0
+ provider registry.terraform.io/hashicorp/aws v5.84.0
+ provider registry.terraform.io/hashicorp/awscc v1.27.0
+ provider registry.terraform.io/hashicorp/external v2.2.3
+ provider registry.terraform.io/hashicorp/local v2.2.3
+ provider registry.terraform.io/hashicorp/null v3.1.1
+ provider registry.terraform.io/hashicorp/random v3.6.3
+ provider registry.terraform.io/hashicorp/time v0.7.2

This was originally observed on TF 1.10.3 and hashicorp/aws v5.30.0 but I've confirmed it on latest as well.

Happy to check on the TF 1.11.xx alphas, if you'd like.

Affected Resource(s)

awscc_gamelift_matchmaking_configuration

Terraform Configuration Files

resource "aws_sns_topic" "my_fancy_topic" {
  name = "my-fancy-topic"
}

resource "awscc_gamelift_matchmaking_configuration" "my_fancy_config" {
  name                    = "my-fancy-config"
  description             = "Behold, my fancy config."
  flex_match_mode         = "STANDALONE"
  acceptance_required     = false
  request_timeout_seconds = 600
  ## AWS CC Provider does not allow switching rule sets
  ## https://github.com/hashicorp/terraform-provider-awscc/issues/2099
  rule_set_name       = awscc_gamelift_matchmaking_rule_set.my_fancy_rule_set.id
  notification_target = aws_sns_topic.my_fancy_topic.arn

  lifecycle {
    replace_triggered_by = [awscc_gamelift_matchmaking_rule_set.my_fancy_rule_set]
  }
}

resource "awscc_gamelift_matchmaking_rule_set" "my_fancy_rule_set" {
  name = "my-fancy-ruleset"

  rule_set_body = local.ruleset
}

locals {
  ruleset = jsonencode({
    // The matchmaking ruleset definition (without a name)
    ruleLanguageVersion = "1.0"
    algorithm = {
      strategy              = "exhaustiveSearch"
      backfillPriority      = "high"
      expansionAgeSelection = "oldest"
    }
    playerAttributes = [
      {
        name = "region"
        type = "string"
      }
    ]
    rules = [
      // Generic rules
      {
        name         = "players_share_a_region"
        description  = "All players have the same region"
        type         = "comparison"
        operation    = "="
        measurements = "flatten(teams[*].players.attributes[region])"
      },
    ]
    teams = [
      {
        name       = "TeamA"
        maxPlayers = 2
        minPlayers = 2
      },
      {
        name       = "TeamB"
        maxPlayers = 2
        minPlayers = 2
      }
    ]
  })
}

Debug Output

Apologies, Terraform debug output has a large volume of identifying info in it that I'd rather not print on the open internet.

Expected Behavior

After tearing down and re-applying a ruleset, and by doing so forcing the config it's used by to be torn down and re-applied, the new config uses the new ruleset.

Actual Behavior

After tearing down and re-applying a ruleset, and by doing so forcing the config it's used by to be torn down and re-applied, the new config looks like it's using the new ruleset, but it's actually using the old one under the hood. This is not reported in the web console, CLI, or anywhere else. A category 5 spooky bug, as it's really easy to imagine this being user error.

Steps to Reproduce

1. Apply the above first so it's standing. Then, change both the minPlayers fields in the ruleset to 1. Then re-apply.
2. Then use aws gamelift start-matchmaking with appropriate data to punch in two tickets in to the my_fancy_config. The TF above specifies the tickets need matching regions, but you're free to delete that, it's just there to make the ruleset a bit more typical.
3. Use aws gamelift describe-matchmaking to see what happened to the two tickets
4. EXPECTED: the two tickets get matched together (as a 1v1 match)
5. ACTUAL: the two tickets never get matched together, because the config under-the-hood still thinks that the ruleset is the old one.

Important Factoids

We've been able to work around this, which I'll explain how to do in a comment for anyone in the future trying to devops their way through their game dev life.

References

My buddy Kurt already bugged the reason we originally went for this workaround, which has lead to this new exciting bug.

#2099

[FairlySadPanda]

Workaround

This works around both this and #2099, meaning you can use Terraform to update (standalone) Flexmatch rulesets on the fly without manual intervention.

resource "awscc_gamelift_matchmaking_configuration" "my_fancy_config" {
  name                    = "my-fancy-config"
  description             = "My fancy config."
  flex_match_mode         = "STANDALONE"
  acceptance_required     = false
  request_timeout_seconds = 600
  ## AWS CC Provider does not allow switching rule sets
  ## https://github.com/hashicorp/terraform-provider-awscc/issues/2099
  rule_set_name           = awscc_gamelift_matchmaking_rule_set.my_fancy_ruleset.name
  notification_target     = var.sns_arn ## just some SNS arn somewhere, assuming you're using SNS

  lifecycle {
    ignore_changes = all
  }
}

resource "awscc_gamelift_matchmaking_rule_set" "my_fancy_ruleset" {
  name = "my-fancy-ruleset-${random_string.random.result}"

  rule_set_body = "{}" ## just feed your json_encoded ruleset in here

  lifecycle {
    create_before_destroy = true
  }

  provisioner "local-exec" {
    command = "aws gamelift update-matchmaking-configuration --name my-fancy-config --rule-set-name ${awscc_gamelift_matchmaking_rule_set.my_fancy_ruleset.name} || true"
  }
}

resource "random_string" "random" {
  keepers = {
    rule_set = "" ## hash your json-encoded ruleset and stick it here
  }

  length  = 8
  special = false
}

Explanation

Because of #2099 you can't update a STANDALONE ruleset in place. But this bug means that you can't just tear the config down. Also tearing the config down probably causes weird behaviour for end users who were in that config already and we'd rather avoid that.

Using create_before_destroy we can pull up a new ruleset first. Because we're pulling it up first, we can abuse local-exec to get whatever's running this - which ergo has aws auth - to just run the update-matchmaking-configuration itself directly. We suppress the error from this - as it's expected to if this is a cold apply rather than a patch, and if this command fails we'll error if we try and remove the old ruleset anyway. After hotpatching the config, we can delete the old ruleset.

---

Hope the above helps anyone else who runs into this. Appreciate this is a weird and deeply niche bit of the AWS product stack.