incorrect order of precedence for SNOWFLAKE_ACCOUNT variable

[coleheflin-gt]

Terraform CLI and Provider Versions

Terraform v1.6.1
Snowflake Labs 0.80.0

Terraform Configuration

terraform {

  required_version = ">= 1.6.1"

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

provider "snowflake" {
  account       = local.snowflake_account
  authenticator = "JWT"
}

provider "snowflake" {
  alias         = "account_admin"
  role          = "ACCOUNTADMIN"
  account       = local.snowflake_account
  authenticator = "JWT"
}

provider "snowflake" {
  alias         = "security_admin"
  role          = "SECURITYADMIN"
  account       = local.snowflake_account
  authenticator = "JWT"
}

provider "snowflake" {
  alias         = "sys_admin"
  role          = "SYSADMIN"
  account       = local.snowflake_account
  authenticator = "JWT"
}

Expected Behavior

Based on the terraform docs (scroll to the bottom), "The Snowflake provider will use the following order of precedence when determining which credentials to use: 1) Provider Configuration 2) Environment Variables 3) Config File".

We are expecting the local.snowflake_account variable to be used by the snowflake provider.

Actual Behavior

We are passing in the snowflake account directly into the provider and we also have an environment variable called SNOWFLAKE_ACCOUNT. The account passed directly into the provider is being overwritten and the value in the SNOWFLAKE_ACCOUNT environment variable is being used.

Steps to Reproduce

1. Set an env variable SNOWFLAKE_ACCOUNT to an account
2. Pass a different snowflake account into the provider (you may need to specify JWT auth, this wasn't happening before we switched to it)
3. run a plan and check which account the queries go to

How much impact is this issue causing?

High

Logs

No response

Additional Information

No response

[sfc-gh-asawicki]

Hey @coleheflin-gt. Thanks for reporting the issue.

This is still a blowback after unfortunate #2126. BTW, the documentation needed to be corrected before (now and before the refactor documentation was wrong).

I will talk with the team. We have to decide:

• what precedence do we ultimately want (is the one in the docs the desired one)?
• When can we make the change so as not to break the existing configurations?

I will get back to you as soon as we have any conclusions.

[coleheflin-gt]

@sfc-gh-asawicki Thanks for the quick response, that makes sense!

My preference is to maintain the existing order of precedence outlined in the documentation. When we explicitly pass a value into a provider it should take precedence otherwise it will lead to confusion of where that value is being set. In our scenario, the production snowflake account value was set as an environment variable (for a different repository not related to snowflake terraform work) and I was on the terraform staging workspace expecting to be making changes in staging (since the staging account is passed into the provider explicitly) but I was running tf plans in production instead. Luckily the build was broken due to some changes so I never actually applied changes in production (when I thought I was in staging).

To minimize breaking changes, perhaps your team could implement logging when a plan/apply occurs that displays which account it is set to and where it got it from.

I realize you have to take into account many team's use cases, but I hope the described situation is helpful in your team coming to a decision! Thanks for the support on this.

[AZenat]

It actually impacts all environment variables, not only SNOWFLAKE_ACCOUNT.

[sfc-gh-asawicki]

Hey @AZenat @coleheflin-gt. We will work on this issue this week. I hope it will land with the next week's release. I will keep you posted.

[sfc-gh-asawicki]

Hey @AZenat @coleheflin-gt. 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!

[coleheflin-gt]

@sfc-gh-asawicki Thanks for the update. We upgraded to the 0.87.0 and it works as expected! The issue has been resolved. Thanks for the work on this.

[sfc-gh-asawicki]

Great! I'm closing the issue then.