Task after = [...] issues in the 76 release

[rmargarint-nydig]

Terraform CLI and Provider Versions

76

Terraform Configuration

.

Expected Behavior

After the 76 release Task DAGs created through TF seem to have issues related to how the after = [...] is handled. According to the docs the predecessor tasks should be specified in the form of after = [snowflake_task.parent_task.name], which has been working fine for us for a long time. After upgrading to the 76 release (which from the PR seems to have changes related to how the after clause is handled) 100% of our tasks using after are failing.

Actual Behavior

The failure scenarios are complex and hard to describe in detail, but they fall in roughly these situations:

• when using after = [snowflake_task.parent.name] and the task is already present, tf apply says there's an external change where the external state for after is "DB.SCHEMA.parent" but TF only expects "parent". Then during the actual apply it fails because TF apply seems to no longer correctly set the root task in suspended mode (and looking at the snowflake logs that's because it tries to "alter task parent suspend", when it should be doing "alter task db.schema.parent suspend".

• if we change it to after = ["db.schema.parent"] the above error goes away but now another error appears during apply where when it creates/updates the child task, it seems to re-fully qualify the parent name, so the snowflake error is because it's trying to use DB.SCHEMA."DB.SCHEMA.parent" for what it actually sends to snowflake.

Steps to Reproduce

1. terraform apply

How much impact is this issue causing?

High

Logs

No response

Additional Information

No response

[sgavrilov-rbi]

I just run into this issue too. We're trying to upgrade from 0.69.0 to 0.80.0, and we have multiple tasks defined with after = [task.parent.name] (just like the docs suggest). After switching to 0.80.0, the terraform plan detected changes in those tasks like the following:

  ~ resource "snowflake_task" "task" {
      ~ after                                    = [
          - "parent",
          + "db.schema.parent",
        ]
    }

And then failed to apply them. Looking at the DEBUG logs, I found this line:

[DEBUG] provider.terraform-provider-snowflake_v0.80.0: time="2023-12-19T14:09:09Z" level=error msg="error: 002003 (02000): SQL compilation error:\nTask 'db.schema.\"db.schema.parent\"' does not exist or not authorized." func="gosnowflake.(*snowflakeConn).queryContextInternal" file="connection.go:396"

As a workaround, setting after to fully qualified name (i.e after = ["db.schema.parent"]) seems to solve the issue since TF stops detecting changes and does not apply anything. But I'm hesitant to apply this workaround everywhere in our codebase because it doesn't feel right.

[shinoki-lit]

This issue happened to me. I upgraded v0.73 to v0.80.0.

[sfc-gh-hachouraria]

Fuller steps to reproduce (unable to edit original description, posting as a comment to aid the issue's progress/self-test):

1. Use the provider version 0.69.0, and create two tasks:

terraform {
  required_providers {
    snowflake = {
      source  = "Snowflake-Labs/snowflake"
      version = "0.69.0"
    }
  }
}

provider "snowflake" {
  [… snipped …]
}

resource "snowflake_task" "parent_task" {
  comment = "my parent task"

  database  = "MY_DB"
  schema    = "MY_SCH"
  warehouse = "MY_WH"

  name          = "MY_PARENT_TASK"
  schedule      = "10 MINUTE"
  sql_statement = "select * from snowflake_sample_data.tpch_sf1.orders limit 1;"

  user_task_timeout_ms = 10000
  enabled              = true
}

resource "snowflake_task" "child_task" {
  comment = "my child task"

  database  = "MY_DB"
  schema    = "MY_SCH"
  warehouse = "MY_WH"

  name          = "MY_CHILD_TASK"
  sql_statement = "select * from snowflake_sample_data.tpch_sf1.orders limit 10;"

  user_task_timeout_ms = 10000
  after                = snowflake_task.parent_task.name
  enabled              = true
}

2. Run terraform init -upgrade, terraform plan, and terraform apply while using the 0.69.0 version

3. Tasks are created normally.

4. Make no resource changes, and only increase the version of the provider to 0.83.1 (latest as of 2024-01-16)

terraform {
  required_providers {
    snowflake = {
      source  = "Snowflake-Labs/snowflake"
      version = "0.83.1"
    }
  }
}

provider "snowflake" {
  [… snipped …]
}

resource "snowflake_task" "parent_task" {
  comment = "my parent task"

  database  = "MY_DB"
  schema    = "MY_SCH"
  warehouse = "MY_WH"

  name          = "MY_PARENT_TASK"
  schedule      = "10 MINUTE"
  sql_statement = "select 'parent';"

  user_task_timeout_ms = 10000
  enabled              = true
}

resource "snowflake_task" "child_task" {
  comment = "my child task"

  database  = "MY_DB"
  schema    = "MY_SCH"
  warehouse = "MY_WH"

  name          = "MY_CHILD_TASK"
  sql_statement = "select 'child';"

  user_task_timeout_ms = 10000
  after                = snowflake_task.parent_task.name
  enabled              = true
}

5. Run again terraform init -upgrade, terraform plan (changes are detected, mainly to add suspend_task_after_num_failures = 0, but also alters after values), and terraform apply (fails as described) while using the 0.83.1 version

Related comment: #2346 (comment)

[mdefariaborges-rbi]

Hi guys, any news for a bugfix in the next version? Could you tell me if a deadline has already been set for this?

[sfc-gh-asawicki]

Hey, I will be working on this (and #2346) next week. I think we will get this working in v0.86 or v0.87 at the latest.

[sfc-gh-asawicki]

@rmargarint-nydig @sfc-gh-hachouraria @mdefariaborges-rbi @sgavrilov-rbi, together with @sfc-gh-jcieslak we were able to reproduce the issue's cause. The reason was the change in parsing the SHOW TASKS response for after parameter. In earlier versions, the parsing was incorrect for the identifiers containing dot characters. The new one fixed the dot case but Snowflake identifiers surprised us one more time, and the basic case, without any " was not supported correctly.

I prepared a change in the parsing logic, it will be a part of the release next Wednesday/Thursday.

[sfc-gh-asawicki]

Fix released as part of 0.86.0. @rmargarint-nydig @sfc-gh-hachouraria @mdefariaborges-rbi @sgavrilov-rbi, could you please check if bumping solves the issue for you?

[shinoki-lit]

@sfc-gh-asawicki Thank you for your contribution. I upgraded from v0.73 to v0.86 and it successfully works.

[cmogren-rbi]

@sfc-gh-asawicki I can confirm that we could finally update from 0.69.0! I'm fine with closing this ticket.

[sfc-gh-asawicki]

We have two confirmations, so I will close it. @rmargarint-nydig please open another ticket if the error persists for you in the newest provider version.

[roberto-ross-verato]

I tried using 0.88.0 and 0.86.0 versions, both still have the same issue, please, reopen the issue.

[sfc-gh-asawicki]

Hey @roberto-ross-verato. Thanks for reaching out to us.

We have multiple confirmations that the described problem was solved with v0.86.0, so yours may differ. Please open a new issue with the description, example config, and reproduction steps.