Fix #7376 - azurerm_storage_data_lake_gen2_filesystem crashes during plan if SA deleted

[storey247]

added fix to check storage account exists before attempting to read the filesystem
added test
changed filesystem acc tests to use hns

This PR address the issue #7376

[ArcturusZhang]

Hi @storey247 thanks for this PR!

While this PR looks great to me, I have a question about this. Based on the details you posted in #7376 , the error message is a context deadline exceeded.

Could I understand these two resources like that you have a resource group and another resource inside it, and then you delete the resource group in some other approach? In short words, on portal, if we delete storage account, would the file system be deleted along with it? If so, this makes this issue smell more like an issue with the service itself rather than we should do something in the provider.

[storey247]

@ArcturusZhang this is an excellent point, and when I first started investigating the issue and working on a fix, I was looking at fixing in the giovanni client that gets used. However, looking at the logic there, it seemed that there was a deliberate separation between the concerns of retrieving storage account properties and retrieving filesystem properties.

I therefore took the decision that to fix the issue it was probably best to take the approach in this PR, use the SA client to check if the storage account exists before using the filesystem client to retrieve the filesystem properties.

[stuartleeks]

Hi @ArcturusZhang - if I've understood correctly, I think you are suggesting that context deadline exceeded isn't the most helpful response when getting properties for a filesystem where the storage account doesn't exist? If so, I completely agree and would love to see a more helpful error response for this scenario. I'm not sure what the timescales for that would be?

[ArcturusZhang]

Hi @storey247 and @stuartleeks My initial though is that this should be a valid work-around rather than a fix, which may hide something wrong behind the curtain. But as a valid work-around, this indeed will fix the corresponding issue. I personally think this should be good to go.

In the meantime, it would be best if we could make a new issue about the error message. The error comes from giovanni the storage data plane SDK, and in giovanni it comes from go-autorest (according to offline discussion with Tom)

[tombuildsstuff]

LGTM - thanks for this @storey247

[ghost]

This has been released in version 2.18.0 of the provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. As an example:

provider "azurerm" {
    version = "~> 2.18.0"
}
# ... other configuration ...

[ghost]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks!