Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
azurerm_storage_account - fix hanging destroy caused by multipl… (#5565)
Fix for issue #5434 (and related issues: #5530 , #3156 ) * **Problem:** If you have a storage account with more than one network rule set - the destroy action hangs forever and the real destroy/deletion of the resource never happens. If you have a storage account with zero or one network rule attached then this problem is irrelevant - the destroy action completes successfully. * **Reason:** In the `resourceArmStorageAccountDelete` method located in _azurerm/internal/services/storage/resource_arm_storage_account.go_ there is a string array which is passed to the mutex lock method `locks.MultipleByName`. The reason for the problem is that the creation of this array does not cover all possible cases. The logic of the method assumes that you have different virtual networks and inserts them into the array used for locking but does not work correctly in the corner case where you have one virtual network with few sub-networks and you are assigning these sub-networks as a network rules to your storage account. Hence the array passed to the lock method contains n-times strings with the same name (same strings). When this array goes to the mutex the first string is used to lock, the second string is used to lock etc. but at the end all the strings are the same and when the first unlock comes - everything is OK but when a second, third or what so ever unlock hits... dead lock there is nothing to unlock because the first unlock already used the string and it was removed and all other unlocks are trying to use something that simply does not exists. * **Resolution:** Check if there are subnets and attach them to the network name hence all the strings used to populate the array are unique and the lock-unlock problem is resolved.
- Loading branch information