[Bug]: Terraform wants to change number precision of return_data_type and argument block for snowflake_masking_policy

[liamjamesfoley]

Terraform CLI Version

1.7.1

Terraform Provider Version

1.0.0

Company Name

chime

Terraform Configuration

resource "snowflake_masking_policy" "masking_policy" {
  name     = var.name
  database = var.database
  schema   = var.schema
  argument {
    name = "VAL"
    type = var.value_data_type
  }
  comment               = var.comment
  body                  = var.masking_expression
  return_data_type      = var.return_data_type
  exempt_other_policies = "false"
}

variable "comment" {
  type    = string
  default = "Managed by Terraform"
}

# ...

module "payday_latitude_and_longitude_policy" {
  source             = "./stack/snowflake/masking-policy"
  name               = "PAYDAY_LATITUDE_AND_LONGITUDE_MASKING"
  database           = "OPERATION_DB"
  schema             = "SECURITY"
  value_data_type    = "NUMBER(10,6)"
  masking_expression = "case when current_role() in ('SYSADMIN','ACCOUNTADMIN', '${local.snowflake_prod_accountadmin_role_okta}', '${snowflake_account_role.payday_role.name}','${snowflake_account_role.glue_etl_edw_role.name}') then val else null end"
  return_data_type   = "NUMBER(10,6)"
}

import {
  to = module.payday_latitude_and_longitude_policy.snowflake_masking_policy.masking_policy
  id = "\"OPERATION_DB\".\"SECURITY\".\"PAYDAY_LATITUDE_AND_LONGITUDE_MASKING\""
}

Category

category:resource

Object type(s)

resource:masking_policy

Expected Behavior

I expect the import to work with no changes.

I originally noticed this as perpetual drift that was causing all applys to fail b/c TF couldn't drop the policy b/c it was set on several columns.

I tried changing the argument block and that didn't do the trick, so I removed it, recreated the policy manually and attempted to import, but I still see issues.

Actual Behavior

return_data_type      = "NUMBER" -> "NUMBER(10,6)" # forces replacement
...
type = "NUMBER" -> "NUMBER(10,6)" 

Steps to Reproduce

Create the masking policy:

CREATE OR REPLACE MASKING POLICY "OPERATION_DB"."SECURITY"."PAYDAY_LATITUDE_AND_LONGITUDE_MASKING" AS ("VAL" NUMBER(10,6)) 
RETURNS NUMBER(10,6) -> case when current_role() in ('SYSADMIN','ACCOUNTADMIN', 'SNOWFLAKE_PROD_ACCOUNTADMIN_ROLE_OKTA', 'PAYDAY_ROLE','GLUE_ETL_EDW_ROLE') 
then val else null end 
COMMENT = 'Managed by Terraform' 
EXEMPT_OTHER_POLICIES = false 
;

Try to import, get changes.

How much impact is this issue causing?

Medium

Logs

No response

Additional Information

I've also noticed that even after creating with number(10,6) the Snowflake UI also returns:

signature
--
(VAL NUMBER)

instead of (VAL NUMBER(10,6) which is probably relateed.

Would you like to implement a fix?

• Yeah, I'll take it 😎

[sfc-gh-jmichalak]

Hi @liamjamesfoley 👋

There are a few things here:

• This was not working correctly before - attribute changes for e.g. NUMBER were suppressed.
• Before v1, we reworked data types in the provider, and our diff suppressors in the relevant resources should be adjusted. We are currently working on this.
• As a workaround, please use ignore_changes meta argument on the affected fields.
• Snowflake does not return type attributes in the signature, but only a name (VAL NUMBER). This means that we can't handle external changes to NUMBER attributes. We will add this to resource documentation.

[liamjamesfoley]

Thanks @sfc-gh-jmichalak , I pulled the resource out of the module and added ignore_changes would be great if this is resolved eventually though :), although I realize it's partially dependent on a behavior change in Snowflake itself.

The only reason we had this in a module is so we can apply the policy in the same place in code, but the masking policy application resource has been unusable until recently (I hope 🤞). Planning to try again early next year now that we're on V1.0.0.

[sfc-gh-jmichalak]

I answered in #1764 (comment). We will fix data types and rework tables early next year. I proposed a couple of workarounds, and I hope this unblocks you.