Partial Resource Create - tainted state

terraform plugin framework version: 1.0.1

we have this tfconfig
resource “awe-resource” “awe-res-name” {
name = “abc”
size = “bcd”

let’s say the resource with the given name attribute is already created by the resource create function,
but the size setting on the resource failed.
As a developer, we know resources got created only modification with size failed, so
we don’t want this resource to be tainted by terraform.

we know there is CLI version to untaint the resource
is there any way to mark the resource as untainted from the terraform provider plugin?

func (r *aweResource) Create(ctx context.Context, req resource.CreateRequest, resp *resource.CreateResponse){
//code for thee successfuly resource creation with the given name
// code for doing modificationsn on the resource like size

Next run will call the update function

func (r *aweResouce) Update(ctx context.Context, req resource.UpdateRequest, resp *resource.UpdateResponse){
// code checks for state difference and found the size is not set,
// it will try to set the size state again as we have resource already in place.

current behavior
user first time runs - terraform apply --auto-approve
create function will create the resource with the given name and it will get an error while doing modification to size.
terraform marks the resource object as tainted
user second time runs - terraform apply --auto-approve
terraform notice this resource object marked as tainted
it will destroy the previous resource with a given name and recreate the resource with name and size.

expected behavior
user first time runs - terraform apply --auto-approve
create function will create the resource with a given name and it will get an error while doing modification to size.
user second time runs - terraform apply --auto-approve
update function will be invoked as we assume the resource is not marked as tainted.
it will find the difference between states and find size is not in sync.
so it will just update the size on top of the resource created with a given name.

Hi @Krishnan-Priyanshu :wave: Thank you for submitting this.

Terraform itself does not support this functionality at this time, neither in Terraform core nor the protocol between core and providers. Therefore it is not currently something that is able to be supported in terraform-plugin-framework or terraform-plugin-sdk.

I’m not a day to day Terraform core maintainer, but my understanding from that team is that core currently does not have the ability to store a new half-state for a given resource in the situation when the resource configuration also contains provisioners, e.g. given

resource "examplecloud_thing" "example" {
  # ...
  provisioner "local-exec" {
    # ...

Terraform would need to handle:

  • Detaching resource instance nodes from any provisioners in the graph
  • State storage for provisioner nodes to track whether they have run or not
  • That the resource instance, while errored, does not need to be tainted (this would require implementation details in Terraform itself, the protocol, and provider SDKs)

It would be up to the Terraform maintainers to decide the prioritization of this effort. If you’re looking to track this effort from the “provider SDKs” side of this, the current issue is Ability to prevent taints on create errors · Issue #330 · hashicorp/terraform-plugin-sdk · GitHub (although it may get migrated out of the terraform-plugin-sdk repository later). There does not appear to be a Terraform core issue attached to the SDK issue though, so while both teams are aware of the limitation, it might be good to have that created for tracking since ultimately effort would need to start on the core side for this functionality.

Hope this helps.

Thank you for the clarification on that topic!

Is there any update on that since January?

I face this issue for my custom provider (using plugin framework) where I have to perform API calls for each element of a resource field.
In case a single API call fails I am in trouble currently since I need to create the whole resource again.

Is there a workaround known for cases like that?

Thanks a lot!

Not that I’m aware of, personally.

To re-echo this, my suggestion would be to raise an issue in the Terraform core issue tracker with your use case(s): Issues · hashicorp/terraform · GitHub