Pre-plan output, showing changes made outside of Terraform, is vague and possible useless.

[rquadling]

Terraform Version

Terraform v1.1.4
on darwin_amd64
+ provider registry.terraform.io/hashicorp/aws v3.73.0

Terraform Configuration Files

Not relevant to issue

Expected Behavior

The pre-plan output should provide enough information to allow the external changes to be reviewed.

Actual Behavior

The pre-plan output is vague, bordering on useless.

Steps to Reproduce

The issue is more about Terraform filtering of the diff than it is about what was filtered. The original issue (#27547) covers several examples of this issue.

Additional Context

The pre-plan output having asked AWS to delete an account. The account is currently marked as "SUSPENDED", but from the pre-plan output, there's no indication as to what account this is.

So all we know here is that an account was suspended. We know at least 2 of the accounts that were NOT suspended, but even with the most optimistic interpretation of this pre-plan output, there's a distinct lack of useful information being presented. And because it is really quite useless, it devalues the output to a point that who knows if it is worth reviewing.

And once you review it and realise something has changed, the amount of time you now need to spend on identifying exactly what has changed ... it all adds up to a bad situation that is easily solved by having some small options around the diff display.

 # aws_organizations_organization.xxxx1_organisation has changed
  ~ resource "aws_organizations_organization" "xxxx1_organisation" {
      ~ accounts                      = [
            # (10 unchanged elements hidden)
            {
                arn    = "arn:aws:organizations::123456789012:account/o-abcdefghij/000000000001"
                email  = "Xxxx.Yyyy+nt-production-compute@xxxx1.co.uk"
                id     = "000000000001"
                name   = "nt-production-compute"
                status = "ACTIVE"
            },
          ~ {
              ~ status = "ACTIVE" -> "SUSPENDED"
                # (4 unchanged elements hidden)
            },
            {
                arn    = "arn:aws:organizations::123456789012:account/o-abcdefghij/123456789012"
                email  = "Xxxx.Yyyy+management@xxxx1.co.uk"
                id     = "123456789012"
                name   = "management"
                status = "ACTIVE"
            },
            # (2 unchanged elements hidden)
        ]
        id                            = "o-abcdefghij"
      ~ non_master_accounts           = [
            # (10 unchanged elements hidden)
            {
                arn    = "arn:aws:organizations::123456789012:account/o-abcdefghij/000000000001"
                email  = "Xxxx.Yyyy+nt-production-compute@xxxx1.co.uk"
                id     = "000000000001"
                name   = "nt-production-compute"
                status = "ACTIVE"
            },
          ~ {
              ~ status = "ACTIVE" -> "SUSPENDED"
                # (4 unchanged elements hidden)
            },
            {
                arn    = "arn:aws:organizations::123456789012:account/o-abcdefghij/000000000002"
                email  = "Xxxx.Yyyy+devops@xxxx1.co.uk"
                id     = "000000000002"
                name   = "devops"
                status = "ACTIVE"
            },
            # (1 unchanged element hidden)
        ]
        # (8 unchanged attributes hidden)
    }

References

• Feature Request: Verbose option for plan #27547
• #1058712097

[crw]

Thanks for the enhancement request! I have a sneaking suspicion this is a duplicate, but off-hand I cannot find a matching issue. In any case, thanks!

[alisdair]

Thanks for reporting this! We identified the issue and have a fix pending in #30685.

The underlying problem was with our logic for always revealing identifying attributes. This was only being applied attributes at the top level of a resource, or in a block. Other object values had a much more minimal concise diff, which was not the intent of the design.

While I wasn't able to reproduce the exact issue with the AWS resource you specified, I did verify the fix against another provider with an equivalent schema, so I'm confident that the linked PR will address the issue if merged.

[github-actions]

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.