Error: insufficient items for attribute "sku"; must have at least 1

[nexxai]

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

Terraform (and AzureRM Provider) Version

Terraform v0.12.5

• provider.azuread v0.4.0
• provider.azurerm v1.29.0
• provider.null v2.1.2

(I've also tried v1.30.0, v1.31.0, and v1.32.0 of provider.azurerm; the issue occurs in all of them)

Affected Resource(s)

This is the problem: we don't know

Terraform Configuration Files

We have several .tf files in this environment; please review the debug log and let me know which one(s) you need to see

Debug Output

https://gist.github.com/nexxai/cce7e4a6b7097484db5963b23ecdb439 - signed via KeyBase

Panic Output

n/a

Expected Behavior

terraform plan should have completed successfully

Actual Behavior

We receive two of these errors:

Error: insufficient items for attribute "sku"; must have at least 1

Steps to Reproduce

1. terraform plan

Important Factoids

We have gone through and confirmed that every single SKU block in every single resource is formatted correctly. We have also tried backing up and then removing each SKU setting from each resource directly from the state file. Finally, in the azurerm_key_vault resources, we have tried every combination of sku and sku_name when we were using the v1.32.0 azurerm_provider

References

• Error running terraform plan on App Service Plan deleted outside of Terraform #3584 - same error, same provider, potentially same resource
• S3 bucket Error: insufficient items for attribute "destination"; must have at least 1 terraform-provider-aws#9048 - same-ish error, different provider
• Error on plan refreshing firehose state: insufficient items for attribute output_format_configuration terraform-provider-aws#8982 - same-ish error, different provider

[blinard]

I was hoping that 1.32.1 of the azurerm provider would address this issue but it looks like it's still present in that version as well (unfortunately). I've tried wiping my state as well and it still persists. :(

Has anyone found a good workaround for this? It's a blocker for me at the moment.

[blinard]

For anyone interested I managed to find a workaround to this:

1. Run terraform state list
2. Review the output, there are likely 1 or more resources listed in your state that you've deleted from Azure (through some method other than terraform destroy).
3. For each offending resource do terraform state rm [resource name]

That's it, in my case I only had 1 offending resource; after deleting it, I could do terraform plan and terraform apply again.

Again, this worked for my scenario but ymmv.

[nexxai]

@blinard We figured that out last night too. There were several App Services and their App Service Plans that had somehow been deleted through the portal, but I'm guessing that when Terraform was confirming their state, since the SKU field didn't even exist (since the App Service Plan was gone altogether), it was failing with the original error. All of this is supposition, but I feel like it makes the most sense?

If true, it would mean that the SKU checking on the various resources are making the assumption that the resource still exists when checking its value, rather than skipping the SKU check altogether.

@tombuildsstuff Thoughts?

[BenoitDoyon]

@blinard That workaround was successful for us as well. My guess is that we did something wrong and de-synced the Terraform state with the actual infrastructure.

In any case, the "Error: insufficient items for attribute "sku"; must have at least 1" error message that's outputted isn't exactly ideal to pinpoint the issue.

[mbfrahry]

Hey @nexxai, I believe this is the same issue as #3584 and was centered around app_service_plan not returning an error on 404 which is an assumption we make throughout the provider. We merged a workaround for #3584 that might unblock you if you feel comfortable testing it out by building the provider off of master. If that doesn't work we'll continue digging until we find the root cause of your issue.

[aweiker]

I am having the same error, however in my case I haven't deleted any app service plans, instead I imported one and then started getting this error. I did notice that when I did an import, the sku was not set correctly in the state file. My guess is that there is an issue with the provider when it queries the state from azure to reconcile state vs. actual. I have tried modifying state to have the correct values, but I have not been successful yet.

[flagbug]

@aweiker Could your issue by any chance be related to #2991?

I noticed that I imported the app service plan via the URL
/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/mygroup1/providers/Microsoft.Web/serverFarms/instance1

instead of

/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/mygroup1/providers/Microsoft.Web/serverfarms/instance1

Notice the capitalization in serverfarms in both URLs. Importing via the first one generated an empty sku and other fields, importing via the second one seems to import all fields perfectly fine.

[runecalico]

@flagbug - What you found exactly described the root cause of my "insufficient items" error, I had deployed a linux ASP, which at the 58 min mark tf died, so after it finally provisioned I tried to import it and... this error kept on popping up and the state info was missing alot of things. Using the all lowercase serverfarms vs serverFarms on the import gave all the required info.

[favoretti]

Since this issue has been reported a long time ago and relates to the version of provider we no longer support - I'm going to close it. Please open a new updated bug report on current versions of terraform and provider if this is still relevant. Thank you.

[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.