-
Notifications
You must be signed in to change notification settings - Fork 433
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SNOW-1869750: [Feature]: don't crash the Provider if the authentication is set to key-pair, but private_key
is not specified
#3322
Comments
hi - thanks for reporting this issue with us. Looks like the provider is crashing when trying to create a connection. To aid troubleshooting, could you please provide a bit more information about the issue ?
Adding Any detail helps and thank you in advance for providing them to us ! |
Thanks a lot for your prompt response. When you said "Looks like the provider is crashing when trying to create a connection.", I looked at my configurations and found out that the environment variable for private key i.e. SNOWFLAKE_PRIVATE_KEY was not set. After setting this, the issue is resolved. |
i'm glad to hear you're unblocked now and could find the source of the issue - thank you for testing it quickly and letting is know ! i'm going to transform this Issue into an enhancement, because i would like to reproduce it for myself and also see if we can do this differently instead of mysteriously panicking when |
It is also an issue in the latest v1.0.1 provider, sadly.
pubBytes, err := x509.MarshalPKIXPublicKey(config.PrivateKey.Public()) Working on a fix. |
proposed a PR for the underlying gosnowflake driver (snowflakedb/gosnowflake#1285) so it could error out gracefully (with a descriptive error message) instead of panicking. |
private_key
is not specified
private_key
is not specifiedprivate_key
is not specified
the gosnowflake side change is merged, and will be part of the next gosnowflake release. Therefore, keeping this one open for a bit until a Provider version is out which has the gosnowflake with the enhancement. |
fix released with gosnowflake 1.13.0, after the Provider is rebased to such version or higher, will be available in the subsequent Provider release |
<!-- Feel free to delete comments as you fill this in --> - Upgrade libraries, tools, and Go version to 1.22. - Add a note about the new field in the driver. - Ignore linter warnings about using the new field (this will be continued in SNOW-1917271). - Replace `ConcatSlices` with `slices.Concat`. - Exclude a listing rule for the generated structs. - Remove `avast/retry-go` library. Use our own solution instead (it was already used in other places before). - Remove `golangci-lint` from tools. It is not needed, because of a custom installation in the Makefile. - Increase a warehouse test timeout. - Fix tests of granting all streamlits and add a note to the docs about the grants. - Remove the deprecated linter. <!-- summary of changes --> ## Test Plan <!-- detail ways in which this PR has been tested or needs to be tested --> * [ ] acceptance tests <!-- add more below if you think they are relevant --> * [ ] … ## References <!-- issues documentation links, etc --> #3322 #3316 ## TODO - Upgrade Go to 1.23 and 1.24 when it's available - Close relevant dependabot PRs.
Hi @ahsanshafiq, We've released v1.0.4 (release, migration guide) with the updated driver to v1.13.0. |
Closing due to inactivity. |
Terraform CLI Version
1.10.2
Terraform Provider Version
0.94.1
Company Name
No response
Terraform Configuration
Category
category:resource
Object type(s)
No response
Expected Behavior
terraform apply tfplan executes without terraform provider crashing.
Actual Behavior
Steps to Reproduce
In Azure pipeline, apply changes using the tfplan file generated in a earlier job, within the same stage.
How much impact is this issue causing?
High
Logs
No response
Additional Information
I am executing terraform apply tfplan in a downstream Azure pipeline job where tfplan was created in an earlier job.
Would you like to implement a fix?
The text was updated successfully, but these errors were encountered: