BUG: doppler_project_member_service_account ordering is not sane

[dcarriger]

I have some Terraform code that gives our CI/CD service access to each environment for a project.

resource "doppler_project_member_service_account" "ci_cd" {
  for_each = var.ci_cd_sa_slug != null ? var.tenant_environment_map : {}

  project              = doppler_project.this[each.key].name
  service_account_slug = var.ci_cd_sa_slug
  role                 = "viewer"
  environments         = sort(keys(each.value))
}

This code creates the service account association just fine...except that environments takes a set, and the ordering of the set determines whether the resource should be replaced.

  ~ resource "doppler_project_member_service_account" "ci_cd" {
      ~ environments         = [
          + "dev",
          + "dev2",
          + "dev3",
            "prod",
            "stg",
          - "dev3",
          - "dev2",
          - "dev",
            "test",
        ]
        id                   = "paradox-olivia-media.service_account.ed8dc790-163b-424d-a16e-b769ab48359e"
        # (3 unchanged attributes hidden)
    }

As you can see, Terraform wants to update this resource in-place to change the ordering. However, Doppler continues to use whatever ordering it wants after the Terraform is applied, so the code is not idempotent and Terraform always reports changes. My assumption is Doppler sorts the set some other way, such as a slug/GUID/etc for the environment, and therefore the API always reports changes because it sorts in that order.

So that leaves my options as either:

• Figure out how Doppler is sorting my environments on a per-environment basis for every single project and always pass in the environments in that order in the Terraform, which requires overriding my set order for all of them (ugh).
• Use an ignore_changes lifecycle hook, and comment/uncomment this as needed to add, update, or remove environments for my projects (also ugh).

I'm open to workarounds if any exist, but I would consider this a bug because Terraform runs should be idempotent and this resource seems to be quite opinionated about what order items are passed into the set and ignores the user's ordering.

[nmanoogian]

Thanks for reporting this @dcarriger! This is definitely an issue with the provider, which should be treating these arrays more like unordered sets.

We're tracking this issue internally under ENG-7578 but we'll keep this issue updated as well.

[nmanoogian]

Thanks again for letting us know about this, @dcarriger! We just shipped a fix for this in v1.6.2. Please let me know if you run into any issues with it!