[Bug]: Plugin Crash when upgrading from 0.99.0 to 0.100.0

[jasonjoneszywave]

Terraform CLI Version

1.7.0

Terraform Provider Version

0.100.0

Company Name

Zywave, Inc

Terraform Configuration

I am trying to get one of our projects up to 0.100.0 and am encountering plugin crash errors. I suspect the issue may lie with import statements as that was the only thing I changed other than the provider version as part of this update. I was on 0.99.0 and in moving to 0.100.0 I had to update snowflake_accounts data source output references in the existing Import statements to account for changes that were made to the data source in 0.100.0.

Category

category:resource

Object type(s)

No response

Expected Behavior

I expected to receive a plan with no changes.

Actual Behavior

Here are the errors I receive:

Error: Request cancelled
│
│ The plugin6.(*GRPCProvider).UpgradeResourceState request was cancelled.
╵
╷
│ Error: Plugin did not respond
│
│ The plugin encountered an error, and failed to respond to the
│ plugin6.(*GRPCProvider).UpgradeResourceState call. The plugin logs may
│ contain more details.

Stack trace from the terraform-provider-snowflake_v0.100.0 plugin:
panic: interface conversion: interface {} is nil, not bool
goroutine 116 [running]:
github.com/Snowflake-Labs/terraform-provider-snowflake/pkg/resources.v0_99_0_AccountStateUpgrader({0x276e6f8, 0xc000a03800}, 0xc00113e270, {0x1f08f60?, 0xc0006903a0?})
github.com/Snowflake-Labs/terraform-provider-snowflake/pkg/resources/account_state_upgraders.go:18 +0x405
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*GRPCProviderServer).upgradeJSONState(0xc0000105e8, {0x276e6f8, 0xc000a03800}, 0xd?, 0x235f676?, 0x14?)
github.com/hashicorp/terraform-plugin-sdk/v2@v2.33.0/helper/schema/grpc_provider.go:491 +0x75
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*GRPCProviderServer).UpgradeResourceState(0xc0000105e8, {0x276e6f8?, 0xc000a03710?}, 0xc001892580)
github.com/hashicorp/terraform-plugin-sdk/v2@v2.33.0/helper/schema/grpc_provider.go:367 +0x3fa
github.com/hashicorp/terraform-plugin-mux/tf5to6server.v5tov6Server.UpgradeResourceState({{0x2787700?, 0xc0000105e8?}}, {0x276e6f8?, 0xc000a03710?}, 0xc001892540?)
github.com/hashicorp/terraform-plugin-mux@v0.15.0/tf5to6server/tf5to6server.go:237 +0x142
github.com/hashicorp/terraform-plugin-mux/tf6muxserver.(*muxServer).UpgradeResourceState(0x276e730?, {0x276e6f8?, 0xc000a03410?}, 0xc001892540)
github.com/hashicorp/terraform-plugin-mux@v0.15.0/tf6muxserver/mux_server_UpgradeResourceState.go:36 +0x19f
github.com/hashicorp/terraform-plugin-go/tfprotov6/tf6server.(*server).UpgradeResourceState(0xc000758140, {0x276e6f8?, 0xc000a02750?}, 0xc000d971d0)
github.com/hashicorp/terraform-plugin-go@v0.22.2/tfprotov6/tf6server/server.go:744 +0x278
github.com/hashicorp/terraform-plugin-go/tfprotov6/internal/tfplugin6._Provider_UpgradeResourceState_Handler({0x22a1f40?, 0xc000758140}, {0x276e6f8, 0xc000a02750}, 0xc0007c7e00, 0x0)
github.com/hashicorp/terraform-plugin-go@v0.22.2/tfprotov6/internal/tfplugin6/tfplugin6_grpc.pb.go:446 +0x169
google.golang.org/grpc.(*Server).processUnaryRPC(0xc000a78000, {0x276e6f8, 0xc000a025a0}, {0x2782940, 0xc000268300}, 0xc00115a360, 0xc0008f3770, 0x3859818, 0x0)
google.golang.org/grpc@v1.63.2/server.go:1369 +0xe23
google.golang.org/grpc.(*Server).handleStream(0xc000a78000, {0x2782940, 0xc000268300}, 0xc00115a360)
google.golang.org/grpc@v1.63.2/server.go:1780 +0x1016
google.golang.org/grpc.(*Server).serveStreams.func2.1()
google.golang.org/grpc@v1.63.2/server.go:1019 +0x8b
created by google.golang.org/grpc.(*Server).serveStreams.func2 in goroutine 42
google.golang.org/grpc@v1.63.2/server.go:1030 +0x135
Error: The terraform-provider-snowflake_v0.100.0 plugin crashed!
This is always indicative of a bug within the plugin. It would be immensely
helpful if you could report the crash with the plugin's maintainers so that it
can be fixed. The output above should help diagnose the issue.

Steps to Reproduce

Existing code 0.99.0:

data "snowflake_accounts" "existing_accounts" {}

locals {
existing_accounts = {
for account in data.snowflake_accounts.existing_accounts.accounts : account.account_name => account if contains(keys(local.snowflake_accounts), account.account_name)
}
}

import {
for_each = local.existing_accounts
to = snowflake_account.accounts[each.key]
id = each.value.account_locator
}

Update provider to 0.100.0 and update existing code as follows:

locals {
existing_accounts = {
for account in data.snowflake_accounts.existing_accounts.accounts : account.show_output[0].account_name => account if contains(keys(local.snowflake_accounts), account.show_output[0].account_name)
}
}

import {
for_each = local.existing_accounts
to = snowflake_account.accounts[each.key]
id = each.value.show_output[0].account_locator
}

How much impact is this issue causing?

High

Logs

No response

Additional Information

I also tried provider versions 1.0.0 and 1.0.1 and encountered the same plugin crash. Ultimately this issue is preventing us from getting to 0.100.0 that gives us access to the admin_user_type attribute on the snowflake_account resource. We need this in order to complete the migration to the new service user and legacy service user types that are a part of our account provisioning process.

Would you like to implement a fix?

• Yeah, I'll take it 😎

[DrWaitForIt]

+1

[sfc-gh-asawicki]

Hey @jasonjoneszywave. Thanks for reaching out to us.

We will try to reproduce your issue this week and we'll get back to you.

[sfc-gh-jmichalak]

Hi @jasonjoneszywave 👋

We have a bug in the account state upgrader - this will be fixed in the next release. We suggest upgrading to the newest version after the release.

As a workaround, you can reimport following our resource migration guide. Remove the account from the state, bump the version, and import the account again, omitting the faulty state upgrader.

The alternative is to set the must_change_password and is_org_admin fields in the resource to concrete values.

[jasonjoneszywave]

Hi @sfc-gh-jmichalak

Thanks for the update. I tried going to 0.100.0 and adding is_org_admin (must_change_password was already set) and I'm still encountering the error. Also tried adding in admin_user_type and still fails. Are there other optional attributes that need to be set to get past this issue?

I'd prefer to avoid the direct state manipulation approach since we have 40+ accounts to contend with.

Is getting a 0.100.1 release with the state upgrader fix not an option?

[sfc-gh-jmichalak]

Hi, I was wrong here. This field works in a different way, and its value change is ignored after account creation, so the state stays null, which causes panic.

We are planning to fix this only in v1.0.2 for now (not released yet). If you are not using deprecated objects, you should be able to migrate to v1.0.2 quite easily.

If you are worried about breaking the account state, you can do a backup first and migrate them individually. This means you can create a separate deployment for 1 account, migrate it, and check if everything is okay. Note that any changes detected during terraform apply, terraform destroy, etc, require manual confirmation. The approach I suggested before results is a no-downtime migration, so I think this should work fine.

[jasonjoneszywave]

@sfc-gh-jmichalak Thanks for the additional info! Do you have an estimate of when v1.0.2 will be released? That will help me determine which path to take.

[sfc-gh-jmichalak]

Probably on Friday or early next week.

[sfc-gh-jmichalak]

Hi @jasonjoneszywave, we've just released v1.0.2(release, migration guide). Please let us know if upgrading directly to v1.0.2 solves this issue.

[jasonjoneszywave]

Hi @sfc-gh-jmichalak

I was able to update to 1.0.2 successfully this morning and no longer encounter the errors that were seen on the prior versions. Thanks much for getting this fix in place!

The only additional bit I ran into since I had to go straight from 0.99.0 to 1.0.2 I was unable to do a straightforward migration from snowflake_unsafe_execute to snowflake_execute since those both only exist at the same time in 0.100.0. Luckily in my case I'm doing a merge statement, so I was able to remove the resources from the state files with Terraform RM and then jump to 1.0.2 and add back in as snowflake_execute and everything worked fine with no data duplication. Just wanted to share this in case anyone else out there runs into this and is looking for a solution.