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
terraform applyterraform destroy
Important Factoids
References
About this issue
- Original URL
- State: open
- Created 3 years ago
- Reactions: 2
- Comments: 16 (6 by maintainers)
@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.