panic: runtime error: invalid memory address or nil pointer dereference

[fabio-s-franco]

Is there an existing issue for this?

• I have searched the existing issues

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment and review the contribution guide to help.

Terraform Version

1.7.4

AzureRM Provider Version

3.97.1

Affected Resource(s)/Data Source(s)

azurerm_storage_container

Terraform Configuration Files

resource "azurerm_storage_container" "blob_container" {
  name                  = local.storage_container_name
  storage_account_name  = local.config.storage_account_name
  container_access_type = "private"
}

Debug Output/Panic Output

Error: Plugin did not respond

  with azurerm_storage_container.blob_container,
  on azurerm_storage_containter.tf line 1, in resource "azurerm_storage_container" "blob_container":
   1: resource "azurerm_storage_container" "blob_container" {

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


Stack trace from the terraform-provider-azurerm_v3.97.1_x5 plugin:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x38 pc=0x464ae9f]

goroutine 1509 [running]:
github.com/tombuildsstuff/giovanni/storage/2023-11-03/blob/containers.Client.GetProperties({0xc002125290?}, {0x8f746f8, 0xc00328b960}, {0xc004893628?, 0x8747674?}, {{0x0?, 0x8f5ee38?}})
        github.com/tombuildsstuff/giovanni@v0.25.3/storage/2023-11-03/blob/containers/get_properties.go:53 +0x29f
github.com/hashicorp/terraform-provider-azurerm/internal/services/storage/shim.DataPlaneStorageContainerWrapper.Get({0xc00210be40?}, {0x8f746f8?, 0xc00328b960?}, {0xc004893628?, 0xc002125290?})
        github.com/hashicorp/terraform-provider-azurerm/internal/services/storage/shim/containers_data_plane.go:53 +0x85
github.com/hashicorp/terraform-provider-azurerm/internal/services/storage.resourceStorageContainerRead(0xc001a2b100, {0x7744b20?, 0xc001ff8000?})
        github.com/hashicorp/terraform-provider-azurerm/internal/services/storage/storage_container_resource.go:243 +0x3c2
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).read(0x8f74650?, {0x8f74650?, 0xc0032af980?}, 0xd?, {0x7744b20?, 0xc001ff8000?})
        github.com/hashicorp/terraform-plugin-sdk/v2@v2.29.0/helper/schema/resource.go:783 +0x163
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).RefreshWithoutUpgrade(0xc000f509a0, {0x8f74650, 0xc0032af980}, 0xc002f5f380, {0x7744b20, 0xc001ff8000})
        github.com/hashicorp/terraform-plugin-sdk/v2@v2.29.0/helper/schema/resource.go:1089 +0x552
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*GRPCProviderServer).ReadResource(0xc000a489c0, {0x8f74650?, 0xc0032af890?}, 0xc0027d5480)
        github.com/hashicorp/terraform-plugin-sdk/v2@v2.29.0/helper/schema/grpc_provider.go:649 +0x48a
github.com/hashicorp/terraform-plugin-go/tfprotov5/tf5server.(*server).ReadResource(0xc001c26960, {0x8f74650?, 0xc0032af0e0?}, 0xc002a1c060)
        github.com/hashicorp/terraform-plugin-go@v0.19.0/tfprotov5/tf5server/server.go:789 +0x48b
github.com/hashicorp/terraform-plugin-go/tfprotov5/internal/tfplugin5._Provider_ReadResource_Handler({0x836c6a0?, 0xc001c26960}, {0x8f74650, 0xc0032af0e0}, 0xc00328b340, 0x0)
        github.com/hashicorp/terraform-plugin-go@v0.19.0/tfprotov5/internal/tfplugin5/tfplugin5_grpc.pb.go:431 +0x169
google.golang.org/grpc.(*Server).processUnaryRPC(0xc0002ee1e0, {0x8f9c1a0, 0xc00105d6c0}, 0xc0032be240, 0xc00147e690, 0xe859c68, 0x0)
        google.golang.org/grpc@v1.58.3/server.go:1374 +0xde7
google.golang.org/grpc.(*Server).handleStream(0xc0002ee1e0, {0x8f9c1a0, 0xc00105d6c0}, 0xc0032be240, 0x0)
        google.golang.org/grpc@v1.58.3/server.go:1751 +0x9e7
google.golang.org/grpc.(*Server).serveStreams.func1.1()
        google.golang.org/grpc@v1.58.3/server.go:986 +0xbb
created by google.golang.org/grpc.(*Server).serveStreams.func1 in goroutine 14
        google.golang.org/grpc@v1.58.3/server.go:997 +0x145

Error: The terraform-provider-azurerm_v3.97.1_x5 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 Behaviour

An error instead of an exception. In this case, it's because the container is inaccessible to the deployment agent.

Actual Behaviour

The panic output is about the resource above, but that little piece of code hardly makes justice to the situation.
In a hub/spoke topology and accessibility via private endpoint, I am assuming this is result of an attempt to make a call through the data plane instead of the control plane.
It is a scenario where the storage account and container already exist, but connectivity is lost during the setup of the private endpoint. It is not possible to resolve this situation only with code, because this happens during container listing and that happens before private endpoint is created and after a private dns zone is established.

I am also assuming this seems to be the result of a nil response that is not being properly handled. I thought it was strange that it seemed to have already been addressed in the issue #25378, and recently resolved with tombuildsstuff/giovanni#111

But I realized that the stack trace is not exactly the same. It matches the top of the stack (get_properties.go:53), but differs further down:

• referenced issue: containers_data_plane.go:42
• my issue: containers_data_plane.go:53

So, I guess that is another nil check to fix.

Steps to Reproduce

No response

Important Factoids

In some circumstances, it would be very helpful to have lifecycle ignore_changes, be reflected on data plane calls. It would make lots of situations easier to work around and well, I am not sure why calls to the data plane still happen even when we choose to not track changes that require these calls.

References

I added my reasoning about lifecycle in the issue that tracks the problem of data plane accessibility: #2977 (comment)

[manicminer]

Hi @fabio-s-franco, thanks for reporting. I believe this is actually the same issue as #25378, which unfortunately I closed prematurely, as it seems the upstream PR tombuildsstuff/giovanni#111 was not yet vendored in the provider.

This will be resolved with #25404 in the next provider release. Sorry for the confusion here, there have been a lot of SDK and provider changes flying around with storage resources recently and this one slipped through the cracks.

[fabio-s-franco]

Oh ok, I understand. Got a bit confused, that's all. Thanks for the clarification.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.