Why do timeout failures cause tainted Cloud resources?

You attempted to create an Cloud resource that takes a long time to fully provision, such as Event Streams or Cloud Databases. When you run the Schematics apply action, the action fails due to timeouts results in a tainted resource.

The IBM Cloud Provider Plug-in for Terraform sets certain timeouts when the provisioning, update, or deletion of a resource must be completed before it is considered failed. Because some resources such as Event Streams or Cloud Databases take longer to fully provision, they might exceed these timeouts. If the provisioning cannot be completed before the timeout is reached, the IBM Cloud Provider plug-in marks the provisioning process as failed and taints the resource. However, the actual provisioning of the resource is not canceled and continues in the background, which can result in a successfully provisioned resource after all. Because the resource is tainted, the resource is automatically deleted and re-created when you run the next Schematics apply action.

To avoid that a successfully provisioned resource is deleted and re-created, you must untaint the resource.

List the workspaces in your account and note the ID of the workspace that includes the failed resource.
```
ibmcloud schematics workspace list
```
Refresh your workspace. A refresh action validates the Cloud resources in your account against the state that is stored in the Terraform state file of your workspace. This process might take a few minutes to complete.
```
ibmcloud schematics refresh --id <workspace_ID>
```
Retrieve the template ID of your workspace. To template ID is shown as a string after the Template Variables for: <template_ID> section of your CLI output.
```
ibmcloud schematics workspace get --id <workspace_ID>
```
Retrieve the Terraform state file for your workspace and note the name of the resource that is tainted.
```
ibmcloud schematics state pull --id <workspace_ID> --template <template_ID>
```
Verify that the tainted resource is successfully provisioned and in a working correctly state by using the IBM Cloud console, CLI, or API. For example, if you tried to provision an IBM Cloud Kubernetes Service cluster, check that the cluster is in a Normal state and that you can successfully connect to the cluster.
Untaint the resource. Enter the name of the tainted resource that you retrieved from the state file in the --address parameter. For example, a cluster resource name from a state file might look like this: ibm_container_vpc_cluster.mycluster.
```
ibmcloud schematics workspace untaint --id <workspace_ID> --address <resource_name>
```
Retrieve the Terraform state file for your workspace again and verify that your resource is marked as untainted.
```
ibmcloud schematics state pull --id <workspace_ID> --template <template_ID>
```