terraform-provider-azuread
terraform-provider-azuread copied to clipboard
azuread_group refresh takes very long and causes high cpu (if group has many members)
Community Note
- Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritise this request
- Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritise the request
- If you are interested in working on this issue or have submitted a pull request, please leave a comment
Terraform (and AzureAD Provider) Version
Terraform v1.0.11 on darwin_amd64
- provider registry.terraform.io/hashicorp/azuread v2.27.0
- provider registry.terraform.io/hashicorp/azurerm v3.17.0
Affected Resource(s)
azuread_group
Expected Behavior
Refresh takes reasonable time, aka not much longer then the actual API request
Actual Behavior
We're having huge groups with over 7000 members and the refresh takes between 8 to 15 min to complete and also causes high cpu.
The raw http calls required to get all group members took 25,475 seconds
Steps to Reproduce
Have a group with 7000+ unique members (maybe less) and refresh the state (terraform plan)
7000 members? Hot damn I did not consider my code being used for that big a number.
What are you doing with the group resource that would require the 7000 users to be referenced in Terraform? Are there other actions on that group that take a lot longer than they should?
I'm working for a company with 1000s of users. One can reach these numbers with that many users pretty quickly.
I don't think the issue is actually in this repository, as not much is done here with the members, except writing it to the state and the paging itself is also not the problem.
Therefore I guess one has to look in the custom SDK used by this provider and look for bottlenecks.
OR the problem could be in Terraform core. 🤔
I'll try getting the group with the SDK directly and report back.
I've checked with the SDK itself and it was working as expected:

A fresh TF configuration with just a azuread_group data source also works just fine:

I have to investigate further what is causing this.
We have also been having this issue, but I found a nice workaround if you only need the group object_id, and don't care about the members.
data "azuread_groups" "this" {
display_names = ["group-name"]
security_enabled = true
}
output "group_id" {
value = data.azuread_groups.this.object_ids[0]
}
But if you need the members... :shrug: