The /instantiate operation can return a 404 whlst also processing the request completely normally. This leads to orphaned objects in the directory, and a resource that cannot successfully Create.
Work around this by polling for the application and service principal that you'd expect to see created out-of-band, whenever a 404 is received. Also set a temporary displayName for the application, as this is the only means we have to identify the resulting object is the one we are looking for.
Unfortunately this means that this workaround cannot be implemented for the azuread_application_from_template resource, since that resource intentionally avoids changing the implicitly created user_impersonation scope - this will get created with nonsensical display names / descriptions in the consent flow. Since the whole point of the standalone resource is to inherit scopes (and other fields) from the template, this makes it infeasible to add this workaround there.
Tested locally by intercepting the response to POST /v1.0/applicationTemplates/4601ed45-8ff3-4599-8377-b6649007e876/instantiate and sending a 404 back to the provider.
The
/instantiateoperation can return a 404 whlst also processing the request completely normally. This leads to orphaned objects in the directory, and a resource that cannot successfully Create.Work around this by polling for the application and service principal that you'd expect to see created out-of-band, whenever a 404 is received. Also set a temporary
displayNamefor the application, as this is the only means we have to identify the resulting object is the one we are looking for.Unfortunately this means that this workaround cannot be implemented for the
azuread_application_from_templateresource, since that resource intentionally avoids changing the implicitly createduser_impersonationscope - this will get created with nonsensical display names / descriptions in the consent flow. Since the whole point of the standalone resource is to inherit scopes (and other fields) from the template, this makes it infeasible to add this workaround there.Tested locally by intercepting the response to
POST /v1.0/applicationTemplates/4601ed45-8ff3-4599-8377-b6649007e876/instantiateand sending a 404 back to the provider.Test results: