This guide was made to aid with creating the GitHub issues, so you can maximize your chances of getting help as quickly as possible. To correctly report the issue, we suggest going through the following steps.
Please, go to the provider’s issues page and search if there is any other similar issue to the one you would like to report. This helps us to keep all relevant information in one place, including any potential workarounds. If you are unsure how to do it, here is a quick guide showing different filtering options available on GitHub. It’s good to search by keywords (like IMPORTED_PRIVILEGES) or affected resource names (like snowflake_database) for quick and effective results. Remember to search through open and closed issues, because there may be a chance we have already fixed the issue, and it’s working in the latest version of the provider.
We’ve put together a list of frequently asked questions (FAQ) and commonly known issues. Please check, If the answer you're looking for is in one of the lists.
It’s common for some Snowflake objects to have special cases of usage in some scenarios.
Mostly, they are not validated in the provider for various reasons.
All of them can result in errors during terraform plan or terraform apply.
For those reasons, it’s worth to check the official Snowflake documentation before assuming it’s a provider issue.
Depending on the situation where an error occurred a corresponding SQL command should be looked at.
Especially take a closer look at the “usage notes” section (for example) where all the special cases should be listed.
Currently, we have a few predefined templates for different types of GitHub issues. Choose the appropriate one for your use case (create an issue). Remember to provide as much information as possible when filling out the forms, especially category and object types which appear in almost every template. That way we will be able to categorize the issues and plan future improvements. When filling out corresponding templates you need to remember the following:
- Bug - It’s important to know the root cause of the issue, that is why we encourage you to fill out the optional fields If you think they can be essential in the analysis. That way we will be able to answer or fix the issue without asking for additional context.
- General Usage - Like in the case of bugs, any additional context can speed up the process.
- Documentation - If there’s an error somewhere in the documentation, please check the related parts. For example, an error in the documentation for stage could be also found in the dependent resources like external tables.
- Feature Request - Before filling out the feature request, please familiarize yourself with the publicly available roadmap in case the problem will be resolved by upcoming plans. Also, it would be helpful to reference the roadmap item if the proposals are closely related. That way, we can take a closer look when doing the planned task.
It depends on the status of the feature. Snowflake marks features as follows:
- Private Preview (PrPr)
- Public Preview (PuPr)
- Generally Available (GA)
Currently, our main focus is on making the provider stable with the most stable GA features, but please take a closer look at our recently updated roadmap which describes our priorities for the next quarters.
Our team is checking daily incoming GitHub issues. The resolution depends on the complexity and the topic of a given issue, but the general rules are:
- If the issue is easy enough, we tend to answer it immediately and provide fix depending on the issue and our current workload.
- If the issue needs more insight, we tend to reproduce the issue usually in the matter of days and answer/fix it right away (also very dependent on our current workload).
- If the issue is a part of the incoming topic on the roadmap, we postpone it to resolve it with the related tasks.
The releases are usually happening once every two weeks, mostly done on Wednesday.
As noted at the top of our README, the project is still experimental and breaking change may occur. We try to minimize such changes, but with some of the changes required for version 1.0.0, it’s inevitable. Because of that, whenever we introduce any breaking change, we add it to the migration guide. It’s a document containing every breaking change (starting from around v0.73.0) with additional hints on how to migrate resources between the versions.
Our current plans are documented in the publicly available roadmap that you can find in our repository. We will be updating it to keep you posted on what’s coming for the provider.
If you would like to contribute to the project, please follow our contribution guidelines.
The provider is simply an abstraction issuing SQL commands through the Go Snowflake driver, so most of the errors will be connected to incorrectly built or executed SQL statements.
To see what SQLs are being run you have to set the TF_LOG=DEBUG environment variable.
To confirm the correctness of the SQLs, refer to the official Snowflake documentation.
Please refer to this document as it describes different approaches of importing the existing Snowflake infrastructure into Terrafrom as configuration. One thing worth noting is that some approaches can be automated by scripts interacting with Snowflake and generating needed configuration blocks, which is highly recommended for large-scale migrations.
Problem: Sometimes you can get errors similar to:
│ Error: Provider produced invalid plan
│
│ Provider "registry.terraform.io/snowflake-labs/snowflake" planned an invalid value for snowflake_schema_grant.schema_grant.on_all: planned value cty.False for a
│ non-computed attribute.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
│
GitHub issue reference Solution: You have to be using at least 1.1.5 version of the Terraform CLI.
Problem: If you are getting connection errors with Snowflake error code, similar to this one:
│
│ Error: open snowflake connection: 390144 (08004): JWT token is invalid.
│
Solution: Go to the official Snowflake documentation and search by error code (390144 in this case).
Problem: From the version v0.78.0, we introduced a lot of provider configuration changes. One of them was deprecating private_key_path in favor of private_key.
GitHub issue reference, Migration Guide reference
Solution: Use a non-deprecated private_key field with the use of the file function to pass the private key.
Problem: When getting stack traces similar to:
│ panic: runtime error: index out of range [2] with length 2
│
│ goroutine 61 [running]:
│ github.com/Snowflake-Labs/terraform-provider-snowflake/pkg/snowflake.SchemaObjectIdentifierFromQualifiedName({0x140001c2870?, 0x103adf987?})
│ github.com/Snowflake-Labs/terraform-provider-snowflake/pkg/snowflake/identifier.go:58 +0x174
Solution: Some fields may expect different types of identifiers, when in doubt check our documentation for the field or the official Snowflake documentation what type of identifier is needed.
Problem: From 0.87.0 version, we are quoting incoming external account identifier correctly, which may break configurations that specified account identifier as <org_name>.<acc_name> that worked previously by accident.
Solution: As specified in the migration guide, use account locator instead.