[Bug]: Failed apply to a snowflake_user password will still update the state of the user's password

[jsnb-devoted]

Terraform CLI Version

1.8.1

Terraform Provider Version

0.92.0

Terraform Configuration

resource "snowflake_user" "service_account" {
  for_each          = local.service_accounts
  name              = each.key
  login_name        = each.value.login_name
  default_role      = each.value.role
  default_namespace = each.value.namespace
  default_warehouse = each.value.warehouse
  comment           = each.value.comment
  password          = try(random_password.snowflake_service_account_passwords[each.key].result, try(jsondecode(data.aws_secretsmanager_secret_version.service_account_creds[each.key].secret_string)["values"]["password"], null))
  rsa_public_key = try(
        trimspace(tls_private_key.snowflake_service_account_key[each.key].public_key_pem), null
  )
  must_change_password = false
}

Category

category:resource

Object type(s)

resource:user

Expected Behavior

I had a plan that was meant to update a password and add a public key:

  # module.account.snowflake_user.service_account["MY_USER"] will be updated in-place
~ resource "snowflake_user" "service_account" {
        id                      = "MY_USER"
        name                    = (sensitive value)
      ~ password                = (sensitive value)
      + rsa_public_key          = (known after apply)
        # (13 unchanged attributes hidden)
    }

That failed because the public key had the header and footer:

╷
│ Error: 003065 (42601): SQL execution error:
│ New public key rejected by current policy. Reason: 'Invalid public key'
│ 

I checked the query history log and found the failed ALTER USER statement as expected however the state must have indicated that the password had been updated when in fact it was still the old password:

  # module.account.snowflake_user.service_account["MY_USER"] will be updated in-place
~ resource "snowflake_user" "service_account" {
        id                      = "MY_USER"
        name                    = (sensitive value)
      ~ rsa_public_key          = <<-EOT
            -----BEGIN PUBLIC KEY-----
            ...
            -----END PUBLIC KEY-----
        EOT
        # (14 unchanged attributes hidden)
    }

Actual Behavior

If an apply for the snowflake_user resource then I would expect TF to not update the state such that it produces the same diff on the subsequent plan.

Steps to Reproduce

Update password and public key values in the snowflake user resource. Provide an invalid public key such that Snowflake will reject the ALTER statement (one option is to include the header/footer). Plan/Apply - confirm that the apply fails. Run another plan and confirm that the snowflake user does not provide a diff despite the password being difference in the state.

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

Hey @jsnb-devoted. Thanks for reaching out to us.

We are currently reworking user resource. I will check the reproduction steps in one of my PRs and let you know.

[sfc-gh-asawicki]

Hey @jsnb-devoted, the fix was included in #3013 and will be released in v0.95.0 today or tomorrow (we have to wrap up a few other PRs before making a release). Please check the migration guide and report any problems.

[sfc-gh-asawicki]

Hey @jsnb-devoted.
We have just released v0.95.0 of the provider. It contains a reworked snowflake_user resource. Please consult the migration guide.

[sfc-gh-asawicki]

Closing the issue due to inactivity. Please create a new one if the issue persists in the newest version of the provider.