Role attribute is ignored in the provider if the corresponding "SNOWFLAKE_ROLE" env variable is set

[pashamartinenko]

Terraform CLI and Provider Versions

Terraform v1.3.7 on linux_amd64

provider registry.terraform.io/snowflake-labs/snowflake snowflake-labs/snowflake v0.74.0

Terraform Configuration

provider "snowflake" {
  // account - pulled from env variable
  // username - pulled from env variable
  // password - pulled from env variable
  // role - pulled from env variable (SNOWFLAKE_ROLE is set to ROLE_1)
}

provider "snowflake" {
  // account - pulled from env variable
  // username - pulled from env variable
  // password - pulled from env variable
  role  = "ROLE_2"
  alias = "role2"
}

resource "snowflake_database" "database1" {
  name                        = "database_name1"
}

resource "snowflake_database" "database2" {
  name                        = "database_name2"
  provider = snowflake.role2
}

Expected Behavior

database_name1 db owner is ROLE_1, database_name2 owner is ROLE_2

Actual Behavior

both database_name1 and database_name2 dbs' owner is ROLE_1

Steps to Reproduce

1. run terraform init, plan, apply in a new workspace using v0.73.0 provider - returns expected result
2. run terraform init, plan, apply in a new workspace using v0.74.0 provider - produces the described issue

How much impact is this issue causing?

Low

Logs

No response

Additional Information

workaround is unsetting SNOWFLAKE_ROLE env variable and assigning role attribute to both providers explicitly

[PedroMartinSteenstrup]

Similar behavior noted after upgrading to v0.82

Terraform v1.5.7
on darwin_arm64
+ provider registry.terraform.io/snowflake-labs/snowflake v0.82.0

My provider file

provider "snowflake" {
  alias                     = "admin_user"
  role                      = "USERADMIN"
  account               = "MR-.OE-"
  user                     = "tf"
  authenticator      = "JWT"
  private_key         = data.vault_generic_secret.snowflake.data["snowflake_tf_snow_key.p8"]
}

and

$ printenv | grep -i SNOWFLAKE_ROLE
SNOWFLAKE_ROLE=SYSADMIN

will result in SYSADMIN being used.

Given we are repeating the same steps for each upgrade for the past year, and we always did export SNOWFLAKE_ROLE="SYSADMIN" as step number 1, something must have changed in the precedence of env var SNOWFLAKE_ROLE vs being set in the provider directly.

[AZenat]

Same issue with v0.86. Which is weird because according to the code, the value written in the provider should override the environment variable.

[sfc-gh-asawicki]

Hey @AZenat @PedroMartinSteenstrup @pashamartinenko. This seems connected to #2294. We plan to rework the configuration completely but because this is really misleading now and can result in unpredicted behavior, we will adjust the current config behavior to what the docs say.

I hope the fix will land next week (0.87.0 or 0.88.0).

[sfc-gh-asawicki]

Hey @AZenat @PedroMartinSteenstrup @pashamartinenko. 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!

[PedroMartinSteenstrup]

I set the variable export SNOWFLAKE_ROLE="SYSADMIN"

I ask Terragrunt to use a hardcoded role

%{if contains(local.provider_roles, "admin_user")}
provider "snowflake" {
  alias                = "admin_user"
  role                 = "USERADMIN"
  account          = "MR-.OE-"
  user                = "tf"
  authenticator = "JWT"
  private_key    = data.vault_generic_secret.snowflake.data["snowflake_tf_snow_key.p8"]
}
%{endif}

Generated provider block honours the hardcoded over the environment variable

provider "snowflake" {
  alias                = "admin_user"
  role                 = "USERADMIN"
  account          = "MR-.OE-"
  user                = "tf"
  authenticator = "JWT"
  private_key         = data.vault_generic_secret.snowflake.data["snowflake_tf_snow_key.p8"]
}

All good on my side ⚡ Thanks!

[sfc-gh-asawicki]

Closing the issue as it was solved and confirmed by @PedroMartinSteenstrup.

@pashamartinenko please open a new one if you still encounter problems using the newest provider version.