Schema for `Optional` + `Computed` to support correct removal plan in framework

In a provider I have the situation that a top-level resource attribute is both Optional and Computed with the corresponding API behavior that ff the attribute is not set during create the upstream API will set it to some value, let’s say it’s "default" string. From then on the value is never changed upstream (re-computed), but the user is free to change it to some desired value.

Now, the behavior that I’m looking for is that if the user removes the attribute from the resource entirely a diff in the plan is generated and I’d be able to send a "null" value upstream so that it can reset it to the default. The problem with the SDK is that no plan is generated, because it’s also marked as Computed. I think that’s a limitation with the SDK.

What would be the correct way to handle such a situation with the new framework?

Hi @timofurrer,
If I understand your question correctly, you essentially want the behavior “default” value for an attribute but that value is coming from an API call rather than a static, hardcoded value.

In the Framework, a default value is implemented using plan modification, you can implement a resource plan modifier that will call your API to set the value of your attribute if the value of the attribute in the configuration is Unknown.

For example, in the Local provider, the file_permission attribute is both Optional and Computed and uses an attribute-level plan modifier to set a default string. Please note that this example uses an attribute plan modifier instead of a resource plan modifier, in your case you would use a resource plan modifier as the Framework currently only supports external API calls for plan modifiers at the resource-level, but conceptually they are very similar.