Random provider idempotency issue

[quentin9696]

Terraform CLI and Provider Versions

Terraform 1.2.7 Random provider v3.4.3

Terraform Configuration

resource "random_string" "start_letter" {
  length  = 1
  upper   = false
  special = false
  numeric = false
}

Expected Behavior

Nothing happened if I apply in v3.4.2 then in v3.4.3

Actual Behavior

TF show a change in the plan

# random_string.start_letter will be updated in-place
  ~ resource "random_string" "start_letter" {
        id          = "h"
        # (11 unchanged attributes hidden)
    }

Steps to Reproduce

1. terraform apply in random provider 3.4.2
2. terraform apply in random provider 3.4.3

How much impact is this issue causing?

High

Logs

No response

Additional Information

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[bendbennett]

Hi @quentin9696 :wave:

If the in-place update is because override_special is being updated from "" to null then I believe that this is as described in resource/random_password+random_string: Prevent override_special differences upgrading from 3.3.2:

For any environment that happened to upgrade to 3.4.2 and save the empty string into state, the replacement plan modifier will allow in-place modification from empty string ("") to null.

[quentin9696]

Hi @bendbennett

Yes, that's because of the empty to nul conversion. Also, since the resource is marked as changed in TF, it trigger changes on resources that use the resource.

Since that change is in the backend with no consequence for the result of the resource, why you can't trigger a change “outside of Terraform” that will only update the statefile without any real resource update in the plan?

For example, the AWS provider do that:

Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the
last "terraform apply" which may have affected this plan:

  # aws_ssm_parameter.ignore_changes_on_value[1] has changed
  ~ resource "aws_ssm_parameter" "ignore_changes_on_value" {
        id          = "xxxx"
        name        = "xxxxx"
      ~ version     = 39 -> 43
        # (8 unchanged attributes hidden)
    }


Unless you have made equivalent changes to your configuration, or ignored the
relevant attributes using ignore_changes, the following plan may include
actions to undo or respond to these changes.

[bflad]

@quentin9696 providers only have access to the existing state, not any configuration, during transparent state upgrades and during resource refresh. Since setting "" is a valid configuration, albeit with the same effect as null/missing, unilaterally updating any "" state to null would then cause unexpected plan differences for anyone using a "" configuration.

Once the resource is applied with version 3.4.3, it should stabilize.

[bendbennett]

@quentin9696 I'm going to close this issue as I believe that @bflad has addressed your question. Please file another issue if you are encountering issues that differ from those described above. Thanks.

[quentin9696]

@bendbennett sure, sorry I forget to close it.

Thank you for you reply..

[github-actions[bot]]

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.