[Bug]: snowflake_grant_database_role - Provider produced inconsistent result after apply

[jakedave]

Terraform CLI Version

1.14.2

Terraform Provider Version

2.11.0

Company Name

No response

Terraform Configuration

terraform {
  required_providers {
    snowflake = {
      source = "snowflakedb/snowflake"
    }
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

provider "snowflake" {
  organization_name = "..."
  account_name      = "..."
  user              = "..."
  authenticator     = "SNOWFLAKE_JWT"

  private_key            = jsondecode(data.aws_secretsmanager_secret_version.snowflake.secret_string)["..."]
  private_key_passphrase = jsondecode(data.aws_secretsmanager_secret_version.snowflake.secret_string)["..."]

  role      = "SECURITYADMIN"
  warehouse = "..."
}

resource "snowflake_grant_database_role" "database_roles" {
  database_role_name = "\"SNOWFLAKE\".\"GOVERNANCE_VIEWER\""
  parent_role_name   = "SNOWFLAKE_GOVERNANCE_VIEWER"
}

## also fails
resource "snowflake_grant_database_role" "database_roles" {
  database_role_name = "SNOWFLAKE.GOVERNANCE_VIEWER"
  parent_role_name   = "SNOWFLAKE_GOVERNANCE_VIEWER"
}

Category

category:grants

Object type(s)

resource:grant_database_role

Expected Behavior

successful terraform apply

Actual Behavior

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # snowflake_grant_database_role.database_roles will be created
  + resource "snowflake_grant_database_role" "database_roles" {
      + database_role_name = "\"SNOWFLAKE\".\"GOVERNANCE_VIEWER\""
      + id                 = (known after apply)
      + parent_role_name   = "SNOWFLAKE_GOVERNANCE_VIEWER"
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

snowflake_grant_database_role.database_roles: Creating...
╷
│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to snowflake_grant_database_role.database_roles, provider "provider[\"registry.terraform.io/snowflakedb/snowflake\"]" produced an unexpected new value: Root object was present, but now absent.
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

Steps to Reproduce

copy configuration followed by:

terraform init
terraform apply

How much impact is this issue causing?

Medium

Logs

No response

Additional Information

This worked for the last several weeks and has suddenly started failing without configuration change

potentially related to: https://github.com/snowflakedb/terraform-provider-snowflake/issues/4211. I have also attempted using 2.10.1 per that thread

The grants do appear correctly after apply:

 > show grants to role SNOWFLAKE_GOVERNANCE_VIEWER;
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| created_on                       | privilege | granted_on    | name                        | granted_to | grantee_name                | grant_option | granted_by |
|----------------------------------+-----------+---------------+-----------------------------+------------+-----------------------------+--------------+------------|
| 2025-12-11 20:47:16.248000+00:00 | USAGE     | DATABASE_ROLE | SNOWFLAKE.GOVERNANCE_VIEWER | ROLE       | SNOWFLAKE_GOVERNANCE_VIEWER | false        |            |
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+

Interestingly, granted_by does not appear. This is consistent when manually making the same grant.

I have not tested against non snowflake database roles

With debug logs, we also see:

❯ TF_LOG_PROVIDER=DEBUG terraform apply
snowflake_grant_database_role.database_roles: Creating...
2025-12-11T16:48:23.975-0700 [DEBUG] provider.terraform-provider-snowflake_v2.11.0: 2025/12/11 16:48:23 [DEBUG] Failed to parse identifier [], err = "incompatible identifier: "; falling back to fully qualified name conversion
...
database role ("SNOWFLAKE"."GOVERNANCE_VIEWER") not found

Would you like to implement a fix?

• [ ] Yeah, I'll take it 😎

[sfc-gh-jmichalak]

Hi @jakedave 👋

I believe this is related to the incorrect parsing of grants into application names, as I have reproduced this locally. We will provide a fix. I don't have any workaround for now.

[jakedave]

@sfc-gh-jmichalak that's great to hear, thank you for the quick response!

[sfc-gh-jmichalak]

This should be fixed in #4288.

[jakedave]

awesome, will test and follow-up here upon release

[ffmc-mayank]

@sfc-gh-jmichalak I also noticed this issue. I am curious why it started showing up suddenly given I didn't change version for tf provider on my side nor did snowflake enable new BCR bundle?

[tomas-miro]

We are experiencing the exact same issue. While the fix does not get merged the best is just to not grant the built-in database roles via TF?

[R-M-D-J]

Same here. Going back to 2.10 did not solve the problem. Snowflake support just confirmed this is a known issue. They suggest to temporary remove the resource (and remove it from state file) and manage the db roles using snowflake_execute.

[Bryan-Meier]

Same issue here when trying to grant something like SNOWFLAKE.DOCUMENT_INTELLIGENCE_CREATOR to an account role. This worked up until today.

[wahlrkr]

Same here with 2.11.0:

Error: Provider produced inconsistent result after apply
│
│ When applying changes to <our_module>, provider "provider[\"registry.terraform.io/snowflakedb/snowflake\"].useradmin" produced an unexpected new value: Root object was present, but now absent.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

when granting SNOWFLAKE.GOVERNANCE_VIEWER db role 😔

[fschomm]

Same here with 2.10.1

[mendhak]

Was there some behind-the-scenes change pushed to cause this (if it was normally there would be a BCR right)? Our pipelines have been working fine until last evening, and broken since this morning with zero terraform changes.

[Andrew-Lindsay42]

Looks like Snowflake's SHOW GRANTS TO DATABASE ROLE <whatever> command has a new type in the granted_to column - for the various built-in database roles in the Snowflake db there's a new grant to the Application "Snowflake".

So that wouldn't have been a BCR change cause it's just a new string in the command results, but unfortunately is breaking the Terraform provider.

Our temporary workaround is to just comment out the resources granting out the built-in roles and remove from state. Not ideal but the existing db role grants don't get removed in SF and once the provider updates the resources can just be readded.

[Bryan-Meier]

@Andrew-Lindsay42 that is exactly what we are seeing. If you look at the query history in Snowflake, you can see the failures around those show statements that the Snowflake Provider is trying to facilitate.

[klockett7]

Root Cause

When a database role has ANY grant to an APPLICATION, the provider's READ operation fails during parsing. (Snowflake Metadata Database is set as an APPLICATION)

The SHOW GRANTS OF DATABASE ROLE query returns rows where granted_to = 'APPLICATION'. The parser in grants_impl.go#L273 only handles ROLE, SHARE, and USER types. When it encounters APPLICATION, it attempts to parse it as a DatabaseObjectIdentifier (expecting "DB"."NAME" format) instead of an AccountObjectIdentifier, causing the parse to fail. This marks the resource as non-existance, producing the "Root object was present, but now absent" error.

This was introduced when a recent BCR bundle (2025_06 or 2025_07) enabled granting database roles to applications.

Fix

PR #4288 (merged today) adds ObjectTypeApplication to the list of account-level objects the parser handles correctly.

Will be available in the next release after v2.11.0.

---

So i think if a future version is able to parse this return, it will resolve the issue. The apply works as expected in Snowflake when run but on the PR we get the error which hinders our auto-merge flow. We've just manually merged the PR's knowing the grants have been applied but would prefer the automated flow

[mansenfranzen]

Same issue here with v2.10.0. Is there a release still planned for this year?

[apgmckayhl]

Now that we know the issue, do we have any idea about when the bug fix release will be rolled into a released version?

[sfc-gh-asawicki]

Hey. The fix is already merged in https://github.com/snowflakedb/terraform-provider-snowflake/pull/4288. We are internally figuring out the timeline for the release. We will update this issue when we have any conclusions.

[apgmckayhl]

Fantastic @sfc-gh-asawicki 👍

[georgeb-accelins]

@sfc-gh-asawicki will the fix only be released into current version or will it be back ported to any prior releases?

[sfc-gh-asawicki]

@georgeb-accelins Only in the newest version, according to our policy: https://docs.snowflake.com/en/user-guide/terraform#new-features-and-fixes.

[sfc-gh-asawicki]

We have just released v2.12.0 (https://registry.terraform.io/providers/snowflakedb/snowflake/2.12.0/docs). Please check the migration guide before bumping.

[jakedave]

@sfc-gh-asawicki @sfc-gh-jmichalak I can confirm the issue is resolved after upgrading to 2.12.0

appreciate the work on this!

[klockett7]

yes! very much appreciate the quick turn around here! we've updated our provider version to 2.12.0 and are error free 😎

[sfc-gh-asawicki]

We have a couple of confirmations that the fix released in v2.12.0 solved the issue. I'm closing this issue. Please open a new one if a similar case happens in v2.12.0, as it may have a different cause that needs to be diagnosed separately.