Shares created and destroy with account names - double Locator in the resource name

[funes79]

Provider Version

"~>0.25.0"

Terraform Version

1.0.9

Describe the bug

Shares are being created with account name (or Snowflake locator) in the name and then terraform fails to destroy the object because it fails with:

The name of the share is ABC.MYSHARE

Error: error dropping this does not seem to be used ACCOUNT_ID.ABC.MYSHARE: 002003 (02000): SQL compilation error:
Share '"ACCOUNT_ID.ACCOUNT_ID.ABC.MYSHARE"' does not exist or not authorized.

In the Query history we see a query coming from the provider trying to drop a share with double quoted account_id + name

DROP SHARE "ACCOUNT_ID.ABC.MYSHARE"

Note: we tested it also with a simple share name MYSHARE (without any dot in the name)

Expected behavior

A clear and concise description of what you expected to happen.

The module should handle the create and drop correctly.

Code samples and commands

Please add code examples and commands that were run to cause the problem.

resource "snowflake_share" "dev_share" {
  name     = "ABC.MYSHARE"
  comment  = "Testing out share."
  accounts = []
}

Additional context

Add any other context about the problem here.

[frahet]

have the same issue here as well

[Anatoli-deBRADKE]

I observe exactly the same behavior.

[simonepm]

This is happening to me as well.

When creating a share like follows:

resource "snowflake_share" "<share_name>" { name = "<share_name>" }

The share is correctly created, but on the next terraform iteration, terraform performs a:

SHOW SHARES IN ACCOUNT;

to check the shares already existing, but the names are displayed as fully qualified names <org_id>.<account_name>.<share_name> instead of <share_name> only.

This lead to failure as <share_name> is not found among the existing shares.

A simple solution would be for the provider to take only the last token by splitting the name on "."

Given this happend to us all today, I think that on Snowflake side is possible they updated the outcome of

SHOW SHARES IN ACCOUNT;

[Anatoli-deBRADKE]

I think this is related to snowflake bundle 2022_03 which has been activated by default in version 6.21 (June 22-23). https://community.snowflake.com/s/article/Pending-Behavior-Change-Log

[simonepm]

For future reference: https://community.snowflake.com/s/article/show-shares-command-ui-data-sharing-changes

[Anatoli-deBRADKE]

I think that one temporary workaround would be to disabble for the moment the bundle 2022_03 in your account.

https://docs.snowflake.com/en/sql-reference/functions/system_disable_behavior_change_bundle.html

select system$disable_behavior_change_bundle('2022_03');

[simonepm]

I see there is a pull request on the go to solve this issue: https://github.com/Snowflake-Labs/terraform-provider-snowflake/pull/1072

[gouline]

Should be resolved in 0.37.0

[foresterr]

What is the status of this, seeing how it's not closed although last comment says it should be resolved?

We seem to be experiencing similar issue, in 0.63 version of the provider. Difference is, we are importing the share instead of creating it first, but after it is successfully imported, on the next run terraform reports share must be replaced due to change of name from <share_id> to <account_id>.<share_id>. Not sure if this would be the same issue or a new one.

We are currently testing with a pretty ancient version of terraform (upgrade coming soon), but I don't think this is something that could be impacted by terraform version?

[sfc-gh-asawicki]

We are closing this issue as part of a cleanup described in announcement. If you believe that the issue is still valid in v0.89.0, please open a new ticket.