### Terraform Version ```shell Terraform v1.2.9 on linux_amd64 (although this has probably been happening for a very long time to hide terraform-plugin-sdk legacy behaviors) ``` ### Terraform Configuration Files ```terraform terraform { required_providers { random = { source = "hashicorp/random" version = "3.4.2" # version = "3.3.2" } } } resource "random_password" "test" { length = 20 } ``` ### Debug Output Can provide if needed. ### Expected Behavior Either no plan difference output or a plan difference output including _every_ attribute change triggering the difference for providers not using the legacy type system flag in the protocol. ### Actual Behavior ```console $ terraform apply random_password.test: Refreshing state... [id=none] Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: ~ update in-place Terraform will perform the following actions: # random_password.test will be updated in-place ~ resource "random_password" "test" { id = "none" # (12 unchanged attributes hidden) } Plan: 0 to add, 1 to change, 0 to destroy. ``` ### Steps to Reproduce 1. `terraform init` with version 3.3.2 2. `terraform apply` 3. `terraform init -upgrade` with version 3.4.2 4. `terraform plan` The issue references also contain a few other reproductions of similar behaviors. ### Additional Context Terraform Cloud UI seems like it was actually able to pick up the "addition" of the attribute being set to `""` from null, so I suspect this is just a CLI plan output issue. We understand why the provider bug occurred, it was an issue on our side of the protocol in the provide code. Inspecting the differences in state after applying the "unexpected" plan showed the change: ```diff 4c4 < "serial": 1, --- > "serial": 3, 28c28 < "override_special": null, --- > "override_special": "", 33,34c33 < "sensitive_attributes": [], < "private": "eyJzY2hlbWFfdmVyc2lvbiI6IjIifQ==" --- > "sensitive_attributes": [] ``` Aside: terraform-plugin-sdk also would do some potentially unexpected things with what it decided to store in state (empty vs null), especially with imported resources and with [maps that have null values](https://github.com/hashicorp/terraform-provider-random/issues/303), so there's other similar reports we've been working through with migrating providers from that to terraform-plugin-framework. This isn't core's fault, however I'm saying this out loud in case there's other bug reports that wind up in this issue tracker about "strange" plans as folks migrate. ### References - https://github.com/hashicorp/terraform-provider-random/issues/306 - https://github.com/hashicorp/terraform-provider-random/issues/314 (Terraform Cloud UI report) - https://github.com/hashicorp/terraform-provider-random/issues/316 - https://github.com/hashicorp/terraform/issues/22335