Ability to prevent taints on create errors

[danawillow]

SDK version

{
  "Path": "github.com/hashicorp/terraform-plugin-sdk",
  "Version": "v1.4.0"
}

Use-cases

Some resources in the Google provider have multiple steps that happen on create. For example, google_project creates a project, but then it also adds a billing account to it and potentially deletes a network from the project. If the project gets created successfully but one of the other steps fails, the resource is tainted, which means retrying the apply after fixing whatever caused it to fail will destroy the project and recreate it, even though it's a perfectly good project. See terraform-google-modules/terraform-google-project-factory#373 for further discussion.

Attempted Solutions

d.SetPartial seems vaguely relevant to what we want, but it's been deprecated (and I'm not positive that it would have actually worked).

Proposal

Basically anything where we, in the provider code, can tell Terraform to please not taint the resource (just like how a failed update doesn't taint it).

References

hashicorp/terraform#21652 (which was solved in a different way)

[paultyng]

I'm not sure if it would work in this case, but would the ability to just return a warning and not an error solve your need? The warning lets you persist the state without a taint but still message to the users (FYI 0.12 diagnostics/warnings are not exposed directly in the SDK yet but are on our near term list to do so, see #74).

[paultyng]

I guess in this case you probably want to halt further downstream usage of computed attributes though, which a warning will not do.

[danawillow]

Exactly- a warning would be a very good solution, but not a fully comprehensive one. This FR becomes more of a nice-to-have if warnings are coming down the road, though. Looking forward to that :)

[alexng-canuck]

Just as an FYI, we have also noticed in the OCI provider that tainting on create errors leads to other side-effects if the tainted resource no longer exists in the service. Upon a destroy, the refresh operation invalidates the resource, but then causes config validation errors if other downstream resources were dependent on the tainted resource: hashicorp/terraform#23886

[alexng-canuck]

After we have called SetId on a resource, is there a reason why it must be tainted even for create errors? What purpose does the tainting serve?

A warning instead of error would be nice.

Not sure if it would cover the situation where we must inform the user with a terminating error that something went wrong and that the Terraform apply shouldn't make any progress, but we still want Terraform to track the resources that may have been created (for a future destroy).

[paultyng]

@alexng-canuck the main problem as I understand it is that provisioners haven't been run and there is nowhere that information is tracked, as they are just run for create, so we'd need a mechanism to track that info to make this work without the taint I think.

[damodhar22]

What is the status on this enhancement. We have a similar requirement to conditionally avoid taint on create errors. As our create operation is an asynchronous operation, it first returns the id and we poll on it with id for the status.
Once we have the id of the resource we do not want to taint it even if the operation fails. We still want to send error for create operation, but we do not want to taint the resource.

[bflad]

Discuss reference: https://discuss.hashicorp.com/t/partial-resource-create-tainted-state/48905