Making FAST stage 1 resman destroy process more reliable

[LucaPrete]

It happened to me multiple times that, when the FAST resman stage destroy process breaks half way through -for whatever reason- and I run terraform destroy again I get:

Error: Unsupported attribute
│
│   on outputs.tf line 226, in locals:
│  226:     tag_keys         = { for k, v in module.organization.tag_keys : k => v.id }
│     ├────────────────
│     │ module.organization is object with 8 attributes
│
│ This object does not have an attribute named "tag_keys".
╵
╷
│ Error: Unsupported attribute
│
│   on outputs.tf line 228, in locals:
│  228:     tag_values       = { for k, v in module.organization.tag_values : k => v.id }
│     ├────────────────
│     │ module.organization is object with 8 attributes
│
│ This object does not have an attribute named "tag_values".

I usually solve this adding a try in the related stage outputs:

...
tfvars = {
    folder_ids       = local.folder_ids
    service_accounts = local.service_accounts
    tag_keys         = { for k, v in try(module.organization.tag_keys, {}) : k => v.id }
    tag_names        = var.tag_names
    tag_values       = { for k, v in try(module.organization.tag_values, {}) : k => v.id }
  }
...

Before committing this fix, I was wondering if we can state why this happens and if we can make any change at the module level. Anyway, the organization module should at most return empty dictionaries, so I don't see anything wrong there:

output "tag_keys" {
  description = "Tag key resources."
  value = {
    for k, v in google_tags_tag_key.default : k => v if(
      v.purpose == null || v.purpose == ""
    )
  }
}

output "tag_values" {
  description = "Tag value resources."
  value = {
    for k, v in google_tags_tag_value.default :
    k => v if !local.tag_values[k].tag_network
  }
}

Thoughts?

[juliocc]

Before committing this fix, I was wondering if we can state why this happens and if we can make any change at the module level. Anyway, the organization module should at most return empty dictionaries, so I don't see anything wrong there:

I've seen this happen before and I know the fix is to add a try, but I've never understood why it happens. +1 to try to figure it out and document it.

[ludoo]

This happens for several things during destroy, there are try statements scattered throughout the codebase to deal with this, but we add them piecemeal only after we see errors. So I don't have a good explanation on the why, but the proposed fixes are good. :)