[Bug]: consumer snowflake_shared_database cannot be destroyed if provider share is dropped/re-created

[simonepm]

Terraform CLI Version

1.9.5

Terraform Provider Version

0.96.0

Terraform Configuration

resource "snowflake_shared_database" "DB_NAME" {
  name = "DB_NAME"
  from_share = "ORG_NAME.ACC_NAME.DB_NAME"
}

Category

category:resource

Object type(s)

resource:share

Expected Behavior

Destroy operation for snowflake_shared_database should not be dependent on the accessibility of its underlying provider database to be able to perform a destruction when needed. Such access can be lost in case the provider database and share gets re-created.

Actual Behavior

When creating an imported database via snowflake_shared_database, if the provider database gets re-created we need to re-create the consumer database as well.

Destroy of snowflake_shared_database fails due to:
Shared database is no longer available for use. It will need to be re-created if and when the publisher makes it available again.

Steps to Reproduce

Create a share from account A to account B
Deploy a snowflake_shared_database in account B sourcing from account A share
Re-create share in account A
Destroy snowflake_shared_database in account B (ERROR)

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-jcieslak]

Hey @simonepm 👋
Thanks for reporting the issue. I'll take a look at it as soon as possible.

[simonepm]

Thanks! As a workaround I am using:

resource "snowflake_unsafe_execute" "CREATE_DATABASE_DB_NAME" {
execute = "CREATE DATABASE DB_NAME FROM SHARE ORG_NAME.ACC_NAME.DB_NAME"
revert = "DROP DATABASE DB_NAME"
}

snowflake_unsafe_execute does not try to use the database context and then works without throwing errors.

[sfc-gh-jcieslak]

Hey @simonepm 👋
I checked the described use case, and it seems to me like a configuration error rather than a bug on the provider side. I tested this in the worksheet and with the use of this configuration. Please, let me know if yours looks similar or if you see something wrong with the one I provided:

provider "snowflake" {
  alias = "producer"
  profile = "secondary_test_account"
  # fill if needed
}

provider "snowflake" {
  alias = "consumer"
  # fill if needed
}

# Producer part

resource "snowflake_share" "provider_share" {
  provider = snowflake.producer
  name = "test_tf_share" # TODO: Rename on third apply
  # TODO: Uncomment after first apply
  # accounts = ["<org_name>.<consumer_account_name>"]
}

resource "snowflake_database" "provider_database" {
  provider = snowflake.producer
  name = "test_tf_database"
}

resource "snowflake_grant_privileges_to_share" "grant_database_usage" {
  provider = snowflake.producer
  privileges = ["USAGE"]
  on_database = snowflake_database.provider_database.name
  to_share = snowflake_share.provider_share.name
}

# Consumer part

# TODO: Uncomment after first apply
# resource "snowflake_shared_database" "consumer_database" {
#   depends_on = [ snowflake_grant_privileges_to_share.grant_database_usage ]
#   provider = snowflake.consumer
#   from_share = "<org_name>.<provider_account_name>.${snowflake_share.provider_share.name}"
#   name = "test_tf_database"
# }

Here's how you can test it yourself (you need 2 accounts for this with proper Snowflake edition):

• First apply: copy paste and run the configuration
• Second apply: uncomment accounts in share and shared_database resource
• Third apply: change share name to recreate it (it will trigger recreation of grant usage, and then recreation of consumer database). After that no changes should be planned.

[simonepm]

Thanks @sfc-gh-jcieslak !
In my trial also provider_database got re-created as well, and not just the share:

Create a share from account A to account B
Deploy a snowflake_shared_database in account B sourcing from account A share
ADD: Re-create database in account A (sorry I did not specify this before)
Re-create share in account A
Destroy snowflake_shared_database in account B (ERROR)

I will try again as well as soon as I have the chance!

[sfc-gh-jcieslak]

Got it, yes please, try to test this yourself. If that's in one deployment unit, I believe that setting a proper dependency could solve this. Also, maybe in this case replace_triggered_by could be used to trigger A database recreation when needed.

[sfc-gh-jcieslak]

Closing due to long inactivity, I hope my approach helped. If you have any further issues, please create another ticket. Thank you :)