sort does not work properly?

[radekg]

The code:

variable "meh" {
  type = "list"
  default = ["b", "a", "d", "c"]
}

resource "aws_route53_record" "etcd_dns_server_discovery_tls" {
  name    = "_etcd-server-ssl._tcp"
  zone_id = "${data.aws_route53_zone.hosted_zone.zone_id}"
  type    = "SRV"
  ttl     = "300"
  records = [ "${formatlist("0 0 %s %s.", var.etcd_server_port, sort(var.meh))}" ]
}

The output in plan:

  + aws_route53_record.etcd_dns_server_discovery_tls
      id:                                        <computed>
      fqdn:                                      <computed>
      name:                                      "_etcd-server-ssl._tcp"
      records.#:                                 "4"
      records.2682421491:                        "0 0 2380 a."
      records.2916409969:                        "0 0 2380 c."
      records.3033518896:                        "0 0 2380 b."
      records.3801445558:                        "0 0 2380 d."
      ttl:                                       "300"
      type:                                      "SRV"

Clearly this isn't sorted properly.

The order after the sort should be:

  + aws_route53_record.etcd_dns_server_discovery_tls
      id:                                        <computed>
      fqdn:                                      <computed>
      name:                                      "_etcd-server-ssl._tcp"
      records.#:                                 "4"
      records.2682421491:                        "0 0 2380 a."
      records.2916409969:                        "0 0 2380 b."
      records.3033518896:                        "0 0 2380 c."
      records.3801445558:                        "0 0 2380 d."
      ttl:                                       "300"
      type:                                      "SRV"

Terraform 0.11.3, aws plugin version 1.9.0 and 1.10.0.

[apparentlymart]

Hi @radekg! Sorry for the confusing result here.

Based on the output here it looks like aws_route53_record is a field of type "set" rather than "list", which means it is not order-preserving. The sort operation is working and causing the formatlist result to be sorted, but that attribute discards the ordering you gave it because it only cares about which strings are present, not what order they are in.

(We can see that it's a set because the keys are arbitrary large numbers, rather than incrementing indices as would be expected for a list.)

AFAIK the underlying Route53 API here also doesn't preserve order, so I think the behavior here is correct, albeit confusing. However, if I'm wrong about that at the Route53 API does respect the ordering here then that suggests an AWS provider bug, in which case we can have our bot move this issue into the AWS provider repository to put it on the radar of the AWS provider maintainers.

[radekg]

Hey @apparentlymart, that does explain the issue I'm seeing. It's confusing, for sure, but makes sense on a second thought.
I was under impression that these hash keys were random but still preserving the original order of what's given to a the records. I guess no need to panic but if there was an option to have these results in the order as specified by formatlist sort, that would be great. That would provide some consistency into my plan, what I'm seeing now is interesting:

  + aws_route53_record.etcd_dns_client_discovery_tls
      id:                                        <computed>
      fqdn:                                      <computed>
      name:                                      "_etcd-client-ssl._tcp"
      records.#:                                 "4"
      records.2682421491:                        "0 0 2380 a."
      records.2916409969:                        "0 0 2380 b."
      records.3033518896:                        "0 0 2380 c."
      records.3801445558:                        "0 0 2380 d."
      ttl:                                       "300"
      type:                                      "SRV"

  + aws_route53_record.etcd_dns_server_discovery_tls
      id:                                        <computed>
      fqdn:                                      <computed>
      name:                                      "_etcd-server-ssl._tcp"
      records.#:                                 "4"
      records.2682421491:                        "0 0 2380 a."
      records.2916409969:                        "0 0 2380 c."
      records.3033518896:                        "0 0 2380 b."
      records.3801445558:                        "0 0 2380 d."
      ttl:                                       "300"
      type:                                      "SRV"

The example is modified by hand to reflect a real world output, the high numbers are only examples. However, what I see is that two different changesets within the same plan get these records in different order. Making that consistent should not be computationally heavy. I could take a look at that but, as described, this does not require a fix.

Thanks for the explanation.

[apparentlymart]

Unfortunately the ordering has already been "lost" to type conversion by the time we render the diff, but we have a new diff rendering planned (see #15180) which exploits the more type information available with the new config language interpreter and we may be able to apply a more consistent sort for sets, even though we can't preserve the order originally given in the config.

[radekg]

Okay, I’ll close this one. Thank you.

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