Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pipe must be replaced without any config change #2560

Closed
toni-moreno opened this issue Feb 26, 2024 · 3 comments
Closed

pipe must be replaced without any config change #2560

toni-moreno opened this issue Feb 26, 2024 · 3 comments
Labels
bug Used to mark issues with provider's incorrect behavior

Comments

@toni-moreno
Copy link

Terraform CLI and Provider Versions

Terraform v1.5.0
on linux_amd64

  • provider registry.terraform.io/snowflake-labs/snowflake v0.86.0

Terraform Configuration

locals {

pipe_map = {
 "MY_DB.MY_SCHEMA.MY_PIPE_1" = {
    "auto_ingest" = true
    "copy_statement" = <<-EOT
    copy into MY_DB.MY_SCHEMA.MY_TABLE_1
    from @MY_DB.PUBLIC.EXTERNAL_STAGE
    PATTERN = 'some_directory/some_file.csv'
    file_format = (format_name = 'MY_SCHEMA.PUBLIC.CRM_CSV')
    
    EOT
    "db" = "MY_DB"
    "integration" = "MY_AZURE_NOTIF_INT"
    "pipe" = "MY_PIPE"
    "schema" = "MY_SCHEMA"
    "schema_id" = "MY_DB.MY_SCHEMA"
  }
}
}

resource "snowflake_pipe" "pipe" {
  for_each = local.pipe_map

  depends_on = [snowflake_table.table]

  provider = snowflake.SYSADMIN

  database       = snowflake_database.db[each.value.db].name
  schema         = each.value.schema == "PUBLIC" ? "PUBLIC" : snowflake_schema.schema[each.value.schema_id].name
  name           = each.value.pipe
  copy_statement = each.value.copy_statement
  auto_ingest    = each.value.auto_ingest
  integration    = each.value.integration

}

Expected Behavior

One created if no changes in the config files, pipes never should be recreated.

Actual Behavior

after created when I exec again (without any config change) "terraform apply" this message is shown.

  # module.xxxx.snowflake_pipe.pipe["MY_DB.MY_SCHEMA.MY_PIPE_1"] must be replaced
-/+ resource "snowflake_pipe" "pipe" {
      ~ copy_statement       = <<-EOT # forces replacement
     copy into MY_DB.MY_SCHEMA.MY_TABLE_1
    from @MY_DB.PUBLIC.EXTERNAL_STAGE
    PATTERN = 'some_directory/some_file.csv'
    file_format = (format_name = 'MY_SCHEMA.PUBLIC.CRM_CSV')
        EOT
      ~ id                   = "MY_DB|MY_SCHEMA|MY_PIPE_1" -> (known after apply)
        name                 = "MY_PIPE_1"
      ~ notification_channel = "https://xxxxxxxxxxxxxxx.queue.core.windows.net/yyyyyyyyyyyy" -> (known after apply)
      ~ owner                = "SYSADMIN" -> (known after apply)
        # (4 unchanged attributes hidden)
    }

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

It happens only in 2 of my 11 previouly created pipes , and always the same pipes. But no changes in any file sinse the last terraform apply

Steps to Reproduce

  1. terraform apply

How much impact is this issue causing?

High

Logs

No response

Additional Information

No response

@toni-moreno toni-moreno added the bug Used to mark issues with provider's incorrect behavior label Feb 26, 2024
@sfc-gh-asawicki
Copy link
Collaborator

Hey @toni-moreno. Thanks for reaching out to us.

Currently, the leading space is not removed while diffing. Can you confirm that removing the whitespace in the first line (before copy into) solves the problem?

@toni-moreno
Copy link
Author

Hello @sfc-gh-asawicki thank you again for your support .

In my case the problem was one trailing whitespace in both pipes, once removed the problem disappeared.

thank you very much!

sfc-gh-asawicki added a commit that referenced this issue Feb 27, 2024
…nt (#2562)

- Run two separate alters in failover group resource
- Handle `.` in failover ids
- Trim leading and trailing space for pipe statement diff suppression
- Unskip part of the integration tests for failover groups

References: #2544 #2560
@sfc-gh-asawicki
Copy link
Collaborator

Hey @toni-moreno . We have released the fix as part of v0.87.0 release. Please follow the migration guide during the update. Please confirm that the issue is resolved in the newest version. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Used to mark issues with provider's incorrect behavior
Projects
None yet
Development

No branches or pull requests

2 participants