terraform-provider-azuread: Error when destroying azuread_application_password

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 1.0.7, azuread provider 2.9.0

Affected Resource(s)

  • azuread_application_password

Actually the output isn’t quite explicit that this is the affected resource; but I suppose it must be.

Terraform Configuration Files

Can’t share our full configuration, but the basic set up is that we have a azuread_application, a azuread_service_principal and a azuread_application_password.

Can try to shrink to a shareable reproduction if needed.

Debug Output

Coming soon, I hope. Though experience does suggest that bugs will often refuse to reproduce when you turn on the debug logs…

Panic Output

Expected Behavior

Resources are successfully destroyed at terraform destroy

Actual Behavior

│ Error: Removing password credential "5e8d9103-f96c-4e85-ad14-8b2d6f3382f7" from application with object ID "126c83a4-aa27-46c3-a382-e2408c2efac5"
│ 
│ ApplicationsClient.BaseClient.Post(): unexpected status 404 with OData
│ error: Directory_ObjectNotFound: Unable to read the company information
│ from the directory.

Steps to Reproduce

  1. terraform apply
  2. terraform destroy

Important Factoids

References

About this issue

  • Original URL
  • State: open
  • Created 3 years ago
  • Reactions: 2
  • Comments: 16 (6 by maintainers)

Most upvoted comments

At this time I’m inclined to mark this as an API bug and will try to raise it upstream with the relevant folks.

@manicminer did you manage to do this? Is there an upstream bug somewhere that I can go vote on? thanks!

If it is only coincidence, it’s becoming a very strong one - we have never hit this prior to 2.9.0 (and continue not to hit it in our regular pipelines) whereas we hit it more often than not at 2.9.0.

(Each of our pipelines sets up and destroys several applications and passwords; just one of these passwords erroring out is enough for the pipeline to fail. So I don’t necessarily mean that we hit it on more than half of our resources).

So yes, I’m fairly convinced that something has changed at 2.9.0.

Thanks @dimbleby, all of this is extremely helpful! We did add some changes in 2.9 that might be related. I’ll dig into this sometime tomorrow 👍

https://gist.github.com/dimbleby/88190ed4b89e0d50542c1e2f86aa109b#file-debug-log

(I’ve removed the client secret and all access tokens that it obtains. All applications etc mentioned in this log are now destroyed, so it doesn’t matter that their details remain visible).

The 404 appears at line 13689.

I have started seeing this when taking the upgrade from azuread 2.7.0 to 2.9.0. I don’t know whether this is causal, or only coincidence.