Data Lookups Return NULL

[FriedCircuits]

Provider Version

0.58.2

Tried many versions

Terraform Version

1.4.2 and 1.3.7

Describe the bug

Data look ups return null for all values.

For example I started with
data "snowflake_system_get_privatelink_config" "this" {}

and tried also with
data "snowflake_system_get_snowflake_platform_info" "this" {}
data "snowflake_current_account" "this" {}

but all return null except for snowflake_system_get_snowflake_platform_info.aws_vpc_ids

every other value is empty.

Expected behavior

data look up returns data

Code samples and commands

provider "snowflake" {
  account  = var.snowflake_account
  region   = "us-east-1"
  role     = "ACCOUNTADMIN"
  username = var.snowflake_username
  password = var.snowflake_password
}

data "snowflake_system_get_privatelink_config" "this" {}
data "snowflake_system_get_snowflake_platform_info" "this" {}
data "snowflake_current_account" "this" {}

output "snowflake_system_get_privatelink_config" {
  value = data.snowflake_system_get_privatelink_config.this
}

output "snowflake_system_get_snowflake_platform_info" {
  value = data.snowflake_system_get_snowflake_platform_info.this
}

output "snowflake_current_account" {
  value = data.snowflake_current_account.this
}

Changes to Outputs:
  + snowflake_current_account                    = {
      + account = null
      + id      = null
      + region  = null
      + url     = null
    }
  + snowflake_system_get_privatelink_config      = {
      + account_name = null
      + account_url  = null
      + aws_vpce_id  = null
      + azure_pls_id = null
      + id           = null
      + ocsp_url     = null
    }
  + snowflake_system_get_snowflake_platform_info = {
      + aws_vpc_ids           = [
          + "vpc-XXXXXX",
        ]
      + azure_vnet_subnet_ids = []
      + id                    = "."
    }

Additional context

I can verify that auth is working because otherwise I would get an error. Same if I change the role that doesn't have access to private. I also tried with a new account and SSH key auth. I logged in the UI with the same account and I am able to get the privatelink info.

[icornett]

I can confirm from TF state with v 0.84.1

    {
      "mode": "data",
      "type": "snowflake_system_get_privatelink_config",
      "name": "this",
      "provider": "provider[\"registry.terraform.io/snowflake-labs/snowflake\"].account_admin",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "account_name": null,
            "account_url": null,
            "aws_vpce_id": null,
            "azure_pls_id": null,
            "id": null,
            "internal_stage": null,
            "ocsp_url": null,
            "regionless_account_url": null,
            "regionless_snowsight_url": null,
            "snowsight_url": null
          },
          "sensitive_attributes": []
        }
      ]
    },
    {
      "mode": "data",
      "type": "snowsql_query",
      "name": "get_privatelink_config",
      "provider": "provider[\"registry.terraform.io/aidanmelen/snowsql\"].integrations",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "id": "cmo8l35i33rhnpu49fpg",
            "name": null,
            "number_of_statements": null,
            "results": "[{\"SYSTEM$GET_PRIVATELINK_CONFIG()\":\"{\\\"regionless-snowsight-privatelink-url\\\":\\\"app-xxxx-zprod.privatelink.snowflakecomputing.com\\\",\\\"privatelink-account-name\\\":\\\"xxxxx.west-us-2.privatelink\\\",\\\"snowsight-privatelink-url\\\":\\\"app.west-us-2.privatelink.snowflakecomputing.com\\\",\\\"regionless-privatelink-ocsp-url\\\":\\\"ocsp.xxxx-zprod.privatelink.snowflakecomputing.com\\\",\\\"privatelink-account-url\\\":\\\"xxxx.west-us-2.privatelink.snowflakecomputing.com\\\",\\\"privatelink-connection-ocsp-urls\\\":\\\"[]\\\",\\\"privatelink-pls-id\\\":\\\"sf-pvlinksvc-azwestus2.my_guid.westus2.azure.privatelinkservice\\\",\\\"regionless-privatelink-account-url\\\":\\\"xxxxx-zprod.privatelink.snowflakecomputing.com\\\",\\\"privatelink_ocsp-url\\\":\\\"ocsp.xxxxxx.west-us-2.privatelink.snowflakecomputing.com\\\",\\\"privatelink-connection-urls\\\":\\\"[]\\\"}\"}]",
            "statements": "SELECT SYSTEM$GET_PRIVATELINK_CONFIG()"
          },
          "sensitive_attributes": []
        }
      ]
    },

[jasonjoneszywave]

We started encountering this issue earlier this week with some of our Snowflake accounts.

We are currently on version 0.90.0 of the provider. Everything had been working fine up through this past Tuesday afternoon.

We started experiencing the issue on Wednesday morning. To make things a bit more challenging the issue was only occurring with a subset of our Snowflake accounts.

What we determined to be the root cause of the issue was that the account parameter QUOTED_IDENTIFIERS_IGNORE_CASE had been set to TRUE late Tuesday afternoon on the accounts that were exhibiting the issue.

This morning, I was able to confirm that setting the QUOTED_IDENTIFIERS_IGNORE_CASE parameter back to the default of FALSE made the issue go away. This isn't ideal, but we at least know what causes it now.

In short, to recreate the issue run the following command in Snowflake:

ALTER ACCOUNT SET QUOTED_IDENTIFIERS_IGNORE_CASE = TRUE;

Then run TF using the snowflake_system_get_privatelink_config data source and access the output to see that nulls are returned.

EDIT: Also wanted to add that running SELECT SYSTEM$GET_PRIVATELINK_CONFIG(); in Snowflake returns the expected values when QUOTED_IDENTIFIERS_IGNORE_CASE is set to TRUE. The issue only occurs via the data source.

[sfc-gh-asawicki]

Hey @jasonjoneszywave. Thanks for the detailed description!

The issue probably comes from the way the underlying request is constructed:

terraform-provider-snowflake/pkg/snowflake/system_get_privatelink_config.go

Line 10 in b576f29

return `SELECT SYSTEM$GET_PRIVATELINK_CONFIG() AS "config"`

.

Reworking the SYSTEM$ function datasources was not our priority for V1, but we were thinking about introducing the generic datasource as a replacement. I will make sure this issue is addressed in it. In the meantime, we will accept contributions following our guidelines.