[Bug]: snowflake_procedure_python doesn't update stored procedure for imports change

[AndrewNorgrenTR]

Terraform CLI Version

Open Tofu v1.8.8

Terraform Provider Version

1.0.3

Company Name

No response

Terraform Configuration

resource "snowflake_procedure_python" "test_sproc" {
  name = "TEST_SPROC"
  database = var.database_name
  schema = var.application_schema_name
  handler = "transform_snowflake.procedures.test.main"
  snowpark_package = 1.26.0
  comment = "Test 4"
  runtime_version  = 3.11
  return_type = "VARCHAR"
  imports {
    path_on_stage = "transform_snowflake.zip"
    stage_location = var.code_stage_fully_qualified_name
  }
  imports {
    path_on_stage = "properties.zip"
    stage_location = var.code_stage_fully_qualified_name
  }
}

Category

category:resource

Object type(s)

No response

Expected Behavior

If you change:

imports {
path_on_stage = "transform_snowflake.zip"
stage_location = var.code_stage_fully_qualified_name
}

to

imports {
path_on_stage = "transform_snowflake2.zip"
stage_location = var.code_stage_fully_qualified_name
}

then I'd expect the stored proc definition to reflect this import change.

Actual Behavior

However, this change does not get reflected in snowflake.

Steps to Reproduce

1. run 'tofu apply'
2. Open Tofu sees a change to the stored procedure - select Yes
3. The change says its successful - however it's not reflected in Snowflake.

How much impact is this issue causing?

Low

Logs

No response

Additional Information

No response

Would you like to implement a fix?

• Yeah, I'll take it 😎

[sfc-gh-asawicki]

Hey @AndrewNorgrenTR. Thanks for reaching out to us.

I will try to reproduce it tomorrow and will get back to you.

[sfc-gh-asawicki]

Hey @AndrewNorgrenTR. A few things:

1. We are not officially supporting OpenTofu yet; please check if you encounter faulty behavior using Terraform.
2. Please share the "terraform plan" output. The imports have no available ALTER command, so they are marked as ForceNew in the provider; such change should require dropping and recreation.
3. Please share the logs with the TF_LOG=DEBUG option.
4. We should see DROP and CREATE SQLs in the logs.

[AndrewNorgrenTR]

Ok thanks @sfc-gh-asawicki

Let me try this out and get back to you.

[AndrewNorgrenTR]

I tested with Terraform with this set up:

$ terraform -version
Terraform v1.10.5
on windows_386

• provider registry.terraform.io/snowflake-labs/snowflake v1.0.3

2. Here is the output from 'terraform plan'
   Terraform will perform the following actions:

snowflake_procedure_python.test_sproc will be updated in-place

~ resource "snowflake_procedure_python" "test_sproc" {
id = ""CI_DB"."APPLICATION"."TEST_SPROC2"()"
name = "TEST_SPROC2"
# (18 unchanged attributes hidden)

  - imports {
      - path_on_stage  = "transform_snowflake.zip" -> null
      - stage_location = "\"CI_DB\".\"APPLICATION\".\"CODE_STAGE\"" -> null
    }
  + imports {
      + path_on_stage  = "transform_snowflake2.zip"
      + stage_location = "CI_DB.APPLICATION.CODE_STAGE"
    }
}

Plan: 0 to add, 1 to change, 0 to destroy.

3. I'm not getting any log output... not sure if I'm doing something wrong or not... Nothing fails though... It says it updates it - but when looking in Snowflake, the stored procedure is not updated.

If if change the arguments field, then terraform does see that as a '1 to add, 1 to destroy' and it will drop the stored proc and create a new one.

[sfc-gh-asawicki]

Hey @AndrewNorgrenTR, thanks for the details. To get the logs, you must have a TF_LOG=DEBUG environment variable set. The easiest way is to change your terraform apply to TF_LOG=DEBUG terraform apply.

The behavior looks strange, though. I will spend some time on it this week (closer to the end of the week).