Add or_replace to task resources

[PaulGolabowski]

We recently had a failed Terraform Apply due to the plugin timing out. The apply was to create 2 new tasks (a root task and a dependent). We usually fix the timing out issue by simply re-running the job from GitHub Actions. This time, though, we got a Snowflake error saying that the dependent task already existed. The only fix was to suspend the root task and drop the dependent via SYSADMIN.

What we'd like to happen is have the explicit "or_replace" option added to the Task resource so that it can be created as a "CREATE OR REPLACE" command instead of a pure "CREATE". Ideally, this option should exist in every resource type that Snowflake supports "CREATE OR REPLACE" syntax.

An alternative would be an easier way to resolve conflicts like this from within Terraform. Or to find a way to fix this plugin timed out bug.

[sfc-gh-swinkler]

i am conflicted on this. on the one hand i want to support every feature that the Snowflake API does. On the other hand, this is not a very "Terraform" way of doing things. Terraform does not normally overwrite existing resources, its better to throw an error.

One thing that might be a better fix is to set partial state, although this could get complicated as it may require special customizeddiff functions to detect if the resource is partially created.

Another possibility is to set the id immediately after creation, and before trying to resume the task. See here: https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/pkg/resources/task.go#L495-L518. I would move the line d.SetId(dataIDInput) immediately before if enabled {. That we even if there is a timeout when trying to resume the task, at least the ID will be set. And you shouldnt have this same problem.

Also, you said that you needed to manually resolve this conflict. Was it not possible to use terraform import in this case?

[danu165]

On the other hand, this is not a very "Terraform" way of doing things. Terraform does not normally overwrite existing resources, its better to throw an error.

For what it’s worth, the AWS provider actually always overwrites existing resources/configurations. Many people prefer this method because it ensures that if someone edits the resource outside of terraform then terraform will remedy it to its intended state. Implementing a provider this way or not is ultimately up to the provider manager, but I wouldn’t say it’s not a terraform way of doing things.

[sfc-gh-jcieslak]

Hey @PaulGolabowski @danu165
In the upcoming v0.99.0 version of the provider, there is a refactor of tasks as part of preparing GA objects for v1. The described issue is most likely connected to the fact that some objects, like tasks, don't have everything in their CREATE statement and additional calls are needed and the state is set after those statements. This may lead to the situation where the task is created, but the follow-up commands fail, leading to the task being created without a Terraform connection (that then leads to already exists issue you are referring to). Before V1, we decided to set state after the create statement so that any error after this create statement will be followed up in the second apply in the Update method. This way, we'll prevent such situations without the need to add the or_replace field that we would like to avoid (mostly because it would lead to confusion). Closing the issue since the issue refers to the very old version of the provider. Please try the v0.99.0 version when it comes out and report a follow-up issue if the problem remains.