Octopus Provider panics after #781

[rayterrill]

Describe the bug A clear and concise description of what the bug is.

We've upgraded to 0.30.5, and the Octopus provider panics. It looks like #781 potentially introduces this issue cc @HuyPhanNguyen

│ The plugin encountered an error, and failed to respond to the plugin6.(*GRPCProvider).ReadResource call. The plugin logs may contain more details.
╵

Stack trace from the terraform-provider-octopusdeploy_v0.30.5 plugin:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x100 pc=0x1014d7190]

goroutine 98 [running]:
github.com/OctopusDeploy/terraform-provider-octopusdeploy/octopusdeploy_framework.(*variableTypeResource).Read(0x1400053c000, {0x101b364b8, 0x14000d82a80}, {{{{0x101b3dd98, 0x14000d4c000}, {0x1019cbd80, 0x14000d45710}}, {0x101b41790, 0x14000a26050}}, 0x14000840c78, ...}, ...)
    github.com/OctopusDeploy/terraform-provider-octopusdeploy/octopusdeploy_framework/resource_variable.go:130 +0x260
github.com/hashicorp/terraform-plugin-framework/internal/fwserver.(*Server).ReadResource(0x140000b6000, {0x101b364b8, 0x14000d82a80}, 0x14000d82ba0, 0x14000d99608)
    github.com/hashicorp/terraform-plugin-framework@v1.11.0/internal/fwserver/server_readresource.go:117 +0x6a0
github.com/hashicorp/terraform-plugin-framework/internal/proto6server.(*Server).ReadResource(0x140000b6000, {0x101b364b8?, 0x14000d82990?}, 0x1400033c1c0)
    github.com/hashicorp/terraform-plugin-framework@v1.11.0/internal/proto6server/server_readresource.go:55 +0x2e0
github.com/hashicorp/terraform-plugin-mux/tf6muxserver.(*muxServer).ReadResource(0x14000228850, {0x101b364b8?, 0x14000d826c0?}, 0x1400033c1c0)
    github.com/hashicorp/terraform-plugin-mux@v0.16.0/tf6muxserver/mux_server_ReadResource.go:35 +0x184
github.com/hashicorp/terraform-plugin-go/tfprotov6/tf6server.(*server).ReadResource(0x14000240780, {0x101b364b8?, 0x14000a7d7a0?}, 0x14000566000)
    github.com/hashicorp/terraform-plugin-go@v0.23.0/tfprotov6/tf6server/server.go:784 +0x228
github.com/hashicorp/terraform-plugin-go/tfprotov6/internal/tfplugin6._Provider_ReadResource_Handler({0x101aefd40, 0x14000240780}, {0x101b364b8, 0x14000a7d7a0}, 0x14000996000, 0x0)
    github.com/hashicorp/terraform-plugin-go@v0.23.0/tfprotov6/internal/tfplugin6/tfplugin6_grpc.pb.go:482 +0x1c0
google.golang.org/grpc.(*Server).processUnaryRPC(0x14000475600, {0x101b364b8, 0x14000a7d710}, {0x101b3fdc0, 0x14000560000}, 0x14000966000, 0x14000369a70, 0x1022c6188, 0x0)
    google.golang.org/grpc@v1.63.2/server.go:1369 +0xb58
google.golang.org/grpc.(*Server).handleStream(0x14000475600, {0x101b3fdc0, 0x14000560000}, 0x14000966000)
    google.golang.org/grpc@v1.63.2/server.go:1780 +0xb20
google.golang.org/grpc.(*Server).serveStreams.func2.1()
    google.golang.org/grpc@v1.63.2/server.go:1019 +0x8c
created by google.golang.org/grpc.(*Server).serveStreams.func2 in goroutine 26
    google.golang.org/grpc@v1.63.2/server.go:1030 +0x13c

Error: The terraform-provider-octopusdeploy_v0.30.5 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.

Expected behavior

Provider should not panic.

Logs and other supporting information Add the output of running tf plan or tf apply along with any errors in the Octopus Server logs.

Screenshots If applicable, add screenshots to help explain your problem.

Environment and versions:

• OS: [e.g. Windows, Linux, OSX]
• Octopus Server Version: [e.g. 2019.6.1]
• Terraform Version: [e.g. 0.12.4]
• Octopus Terraform Provider Version: [e.g. 0.2.0]

Additional context Add any other context about the problem here.

[mjhilton]

@HuyPhanNguyen, it looks like you merged PR#784 to fix this, but perhaps the "Fixes" syntax in the PR description wasn't quite right, and didn't trigger closing this issue. Can you please confirm that that PR was targeted at this issue, and this one can be closed one?

[HuyPhanNguyen]

Yes this have been fix in this PR#784