Snowflake Troubleshooting

This page lists common errors when you connect Sifflet to Snowflake, as reported by Test Connection or in the logs of a source refresh. The errors listed under Monitor Runs appear when a monitor runs.

Connection

Sifflet Rejects the Account Identifier

Symptom

Invalid Snowflake account identifier provided.

Cause: the Account Identifier field of the source isn't a valid Snowflake account identifier. Common mistakes are entering the full URL, a wrong region or cloud suffix, or a missing organization name.

Fix

Find your account identifier as described in Create the Source. Valid formats look like xy12345, xy12345.us-east-1, or orgname-accountname.
Enter only the identifier, without https:// and without .snowflakecomputing.com.

Sifflet's IP Addresses Are Blocked

Symptom

Sifflet's IP address range is not allowed to access your Snowflake account. Please check your network and security configurations.

Cause: a Snowflake network policy on your account or on the Sifflet user blocks Sifflet's IP addresses.

Fix

Get the IP addresses of your Sifflet instance in Settings > Integration Preferences.
Add them to the allowed IP list of the network policy that applies to the Sifflet user (see Network Access).

The Warehouse Can't Be Used

Symptom

Failed to check if warehouse "SIFFLET_WAREHOUSE" can be used.

Cause: the warehouse doesn't exist, its name in the source doesn't match the case of the name in Snowflake, or the Sifflet role doesn't have USAGE on it.

Fix

Run SHOW WAREHOUSES; and check the exact name of the warehouse.
Grant USAGE on the warehouse to the Sifflet role, as in step 1.
Update the Warehouse field of the source if needed, then run Test Connection again.

The Warehouse Is Suspended or Over Its Quota

Symptom

Warehouse "SIFFLET_WAREHOUSE" is suspended. Please resume it or enable auto-resume in your Snowflake account.

Warehouse "SIFFLET_WAREHOUSE" cannot be resumed because its resource monitor has exceeded its quota. Please increase the quota or reset the resource monitor in your Snowflake account.

Cause: the warehouse is suspended and doesn't resume automatically, or a resource monitor prevents it from resuming.

Fix

Enable auto-resume on the warehouse: ALTER WAREHOUSE SIFFLET_WAREHOUSE SET AUTO_RESUME = TRUE;
If a resource monitor is attached to the warehouse, increase its credit quota or wait for its next reset.

Authentication

The Snowflake User Is Disabled

Symptom

User access is disabled. Please check your credentials.

Cause: the Snowflake user configured in the credential is disabled.

Fix

Run SHOW USERS; and check the disabled column of the Sifflet user.
Re-enable it: ALTER USER SIFFLET_USER SET DISABLED = FALSE;

The Credential Is Rejected

Symptom: one of the following errors.

Credentials are invalid. Please check that the credentials you provided are in the correct format and contain the necessary information.

invalid credentials: credentials are not in a valid JSON format

JWT token is invalid.

Cause: the credential isn't valid JSON, misses a key, contains a wrong user name, password, or private key, or the private key doesn't match the public key set on the Snowflake user (JWT token is invalid.).

Fix

Compare the credential in Integrations > Credentials with the format of your authentication method in Create the Credential: key names, quotes, and brackets.
For key pair authentication, check that the private key in the credential matches the public key set on the user (see Snowflake key pair authentication), and that the passphrase is set for an encrypted key. If needed, generate a new key pair and set the new public key on the user.
For password authentication, Snowflake blocks single-factor passwords for service users: switch to key pair authentication.

Permissions

A Snowflake System View Can't Be Accessed

Symptom: one or more errors such as:

Table or view "SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY" cannot be accessed.

The same error can occur for ACCESS_HISTORY, OBJECT_DEPENDENCIES, TABLES, DYNAMIC_TABLE_REFRESH_HISTORY, TAG_REFERENCES, or INFORMATION_SCHEMA.TABLES.

Cause: the Sifflet role doesn't have access to the SNOWFLAKE.ACCOUNT_USAGE views, which Sifflet uses for lineage, data usage, update history, and tags.

Fix

Grant IMPORTED PRIVILEGES on the SNOWFLAKE database to the Sifflet role, as in step 1:
```
GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE SIFFLET_ROLE;
```
Run Test Connection again.

A Database or Schema Can't Be Used

Symptom: one or more errors such as:

Database "ANALYTICS" and schema "SALES" cannot be used.

Columns in schema "ANALYTICS.SALES" cannot be listed. Please check your permissions.

Cause: the Sifflet role doesn't have USAGE on the database or schema, or SELECT on its objects.

Fix

Run the per-schema grants of step 1 for this schema.
Run Test Connection again.

Sifflet Reports Missing Permissions That Your Own Queries Don't Need

Symptom: Sifflet reports a missing permission, but you can query the object when you use the Sifflet role in a Snowflake worksheet.

Cause: Snowflake secondary roles add all the roles granted to your user to your session, so your queries can succeed with privileges that the Sifflet role doesn't have.

Fix

In your worksheet, run USE ROLE SIFFLET_ROLE; then USE SECONDARY ROLES NONE; to use only the Sifflet role.
Check the grants of the role with SHOW GRANTS TO ROLE SIFFLET_ROLE; and SHOW FUTURE GRANTS IN SCHEMA <DATABASE>.<SCHEMA>;, and compare them with Permissions Required.
Add the missing grants from step 1, then run USE SECONDARY ROLES ALL; to restore your session.

Metadata Latency

Recent SQL Transformations or Tags Don't Appear After a Refresh

Symptom: after a refresh, recent lineage links, SQL transformations, or Snowflake tags are missing in Sifflet.

Cause: Snowflake fills the ACCOUNT_USAGE views with a delay of up to 3 hours (see Snowflake Account Usage data latency).

Fix

Wait at least 3 hours after the change, then refresh the source (see Integrations Management).

Monitor Runs

A Monitor on a Secure View Fails With "Error in Secure Object"

Symptom: a monitor run fails with this error:

Could not execute fetching data query on database [<DATABASE>]: error in secure object (the secure view, or one of its underlying objects, is broken or inaccessible).

Cause: the secure view that the monitor queries, or one of the objects it depends on, is broken or can't be accessed. The error occurs on every run until the view is fixed, so Sifflet doesn't retry the run.

Fix

In a Snowflake worksheet, run USE ROLE SIFFLET_ROLE; and query the secure view to reproduce the error.
Fix the view definition or the underlying object, so that the view can be queried again.
Run the monitor again.

A Monitor Fails Because the Private Key Has No Passphrase

Symptom: a monitor run fails with this error:

Could not connect to database [<DATABASE>]. The private key is encrypted but no passphrase was provided. Provide the private key passphrase in the datasource credentials.

Cause: the source uses key pair authentication with an encrypted private key, but the credential doesn't contain the private_key_passphrase key.

Fix

In Integrations > Credentials, edit the credential and add the passphrase of the private key, in the format shown in Create the Credential.
Run the monitor again.