Expose RequiresReplace/ForceNew attributes in provider schema

Hello!

I’m reaching out for guidance with a feature request concerning the provider schema -json command in Terraform.

The proposal is to expose the RequiresReplace/ForceNew details for the attributes of resources in a provider. This is driven by the need to quickly map out which resources might trigger the recreation of infrastructure, allowing for fast feedback before having the need to execute a time-consuming infrastructure plan.

Having proposed this possibility, would it be appropriate to raise this issue within the Terraform Plugin Framework repository? Do you see any potential obstacles I might face? Are there any inconsistencies in the request? Any technical impediments?

I welcome any feedback you might have. Thank you!

Best regards!

Hi @Nachoofra,

RequiresReplace and ForceNew are not part of the Terraform provider schema, hence are not available within Terraform at all to be exposed. This is more apparent within the framework than the SDK, as you can see RequiresReplace is a type of plan modifier, and not actually part of the type definition.

While theoretically possible to include a static value for RequiresReplace in the schema, that would only be useful in the simple cases, as replacement decisions can often be dynamically decided based on a combination of factors. Given that it could only cover a subset of replacement scenarios, it’s probably not something which would be adopted by the CLI in the static schema definition.

Hi @Nachoofra,

As @jbardin stated above, this information is unlikely to be exposed via the provider schemas -json command in Terraform. We have an issue in the terraform-plugin-framework for the framework to expose it’s own provider metadata. I have updated the issue with a link to this discussion as another potential use case for enhanced provider metadata.

But to set expectations, we are not likely to work on this in the near future and this feature would likely only be supported in the framework and not in the SDKv2.

Thank you both for your responses and explanations! I now better understand the limitations of the implementation of this request.

I will be following the issue on the Plugin Framework :ok_hand: