[Enhancement]: Do not produce "fake" changes at TF state file

[EugenKon]

Description

Terraform version is v1.11.3
Resource is acme_certificate

When I run plan/apply I see these changes at our terraformstate.tf file:
It seems that changes are moved around:

@@ -12348,36 +12343,36 @@
             [
               {
                 "type": "get_attr",
-                "value": "dns_challenge"
-              },
-              {
-                "type": "index",
-                "value": {
-                  "value": 0,
-                  "type": "number"
+                "value": "certificate_p12_password"
               }
-              },
+            ],
+            [
               {
                 "type": "get_attr",
-                "value": "config"
+                "value": "account_key_pem"
               }
             ],
             [
               {
                 "type": "get_attr",
-                "value": "certificate_p12_password"
+                "value": "private_key_pem"
               }
             ],
             [
               {
                 "type": "get_attr",
-                "value": "account_key_pem"
+                "value": "dns_challenge"
+              },
+              {
+                "type": "index",
+                "value": {
+                  "value": 0,
+                  "type": "number"
                 }
-            ],
-            [
+              },
               {
                 "type": "get_attr",
-                "value": "private_key_pem"
+                "value": "config"
               }
             ],

Affected Resource(s) and/or Data Source(s)

• N/A

Potential Terraform Configuration

References

No response

Would you like to implement a fix?

None

[jbardin]

Can you give some context as to what you are inspecting here? The serialized state format is not a public interface, so we don't guarantee that semantically equal values are always encoded in the exact same way, but much of the state is given some sort of order for our own convenience.

[EugenKon]

Sorry. Sure.
So structures are the same for the same cluster state. If the state pieces are equivalent it is expected to have them at different places of a list. Or if this is a map then its traverse by keys is not consistent, because elements of this structure does not have order.
But when these structures are dumped they always could be ordered. Eg. we can order keys by names before traversing the map.
This will result no changes to state file if these structures will be dumped in predictable order.

[jbardin]

Yes, but we need some context about what it is you are looking at in the state. What resource attributes are these, what is the type, and are they changing in the resource itself? What version of Terraform is this? When you "dump" the state into a supported format the order should always be the same, but we need to see how you are accessing the state.

[EugenKon]

If I understand correct, you are asking my why I am complaining about this? We are storing state file at git repository. And after each plan/apply we see a lot of changes. Thus the question is: why we see this or that change if a resource was not changed/touched. It would be better to only the actual changes.
We do not work with terraform state for a different purpose other than this.

What version of Terraform is this?

The terraform version is v1.11.3, but we saw these changes for a long time, IIRC from v1.5.0 (this is when I started to use terraform).

What resource attributes are these, what is the type

For this particular case this is acme_certificate resource, but it does not matter. It happens for a various different types of resources.
I do not know what are these attributes are either.

are they changing in the resource itself?

No, for this plan/apply the resource was not changed.

[jbardin]

If you are looking at the raw state file produced by Terraform, the output is not guaranteed to be stable, especially if the version of Terraform has changed. If there is a change in the cli output when using the -json flag to inspect the state or plan, then we should address that as part of the supported format. Guessing the source of what you are seeing above, I think you may be seeing something related to sensitive attributes paths in #36465, which will be ordered for easier comparison in v1.12.

[jbardin]

Closing since the changes above should not be present in v1.12.