Repository navigation
Issue on subsequent request after creating application #3108
Description
Describe the bug
I call the 'Applications.Create()' method for my app registration. This app registration is visible in Azure Portal.
A subsequent request to update application properties via Applications.Update() fails with error message "Resource '1639f4e8-77ac-41d4-9e90-8f206b5c6392' does not exist or one of its queried reference-property objects are not present."
When verifying in the Azure Portal, I do actually see my app registration with the idea mentioned in the error message being said to 'not exist'. => It does exist.
In another scenario, after doing the Applications.Create(), I did as next statement ServicePrincipals.Create(), and this also failed with "The appId \u0027dca53c17-f359-4bd0-a474-56b68d05bd41\u0027 of the service principal does not reference a valid application object."
Again, verifying in Azure Portal, I see this appId being filled in at the app registration.
Now for the weird thing: debugging locally, this does seem to work. It almost sounds like a 'timing' issue, being called to quickly when deployed in an Azure Function. But methods are all called with a proper await and according to documentation respond with the created object and are not asynchronous, where polling is needed for it to be created and then continue.
The exact same code has been running for over a year perfectly and started causing issues in the past week as far as we know. I already updated to the latest nuget package and the issues is the same in versions 5.105.0 as it was in 5.103.0
Expected behavior
It is expected to, when an application is created and the result object is returned, subsequent updates are not throwing an error about it not being found
How to reproduce
described above
SDK Version
5.105.0
Latest version known to work for scenario above?
No response
Known Workarounds
No response
Debug output
Click to expand log
```</details>
### Configuration
_No response_
### Other information
_No response_
Activity
jeromekol commentedon May 7, 2026
we also have the same issue since a week. Using the REST API directly, does not seem to suffer from that problem.
BloodSeaker commentedon May 7, 2026
I just tried the approach with a POST to the serviceprincipal directly and it returns the same error.
JSON response:
{"error":{"code":"Request_BadRequest","message":"The appId '9b8d62b6-e305-443e-a4a8-cfadc950bf00' of the service principal does not reference a valid application object.","details":[{"code":"NoBackingApplicationObject","message":"The appId '9b8d62b6-e305-443e-a4a8-cfadc950bf00' of the service principal does not reference a valid application object.","target":"appId","blockedWord":"","prefix":"","suffix":""}],"innerError":{"date":"2026-05-07T06:55:34","request-id":"6983d5d5-8e44-4055-8ccc-12a7af6b7255","client-request-id":"6983d5d5-8e44-4055-8ccc-12a7af6b7255"}}}If after several minutes, I send the request again, it does work. I am not implementing a retry mechanism to see how long it takes (I am going up to a total of 1 minute). But no documentation is mentioning an eventual consistency and it works for over 1,5 years without problems and suddenly is now causing our production flows to break
jeromekol commentedon May 7, 2026
For us it takes a couple seconds. Eventual consistency was always part of Entra (https://devblogs.microsoft.com/identity/designing-for-eventual-consistency-for-microsoft-entra/) but we also never experienced such a huge lag in the past. Interestingly, we have different Entra tenants, where we don't suffer from high latency.
BloodSeaker commentedon May 7, 2026
I did the test, using the SDK (it does not mention that you need to have a retry policy on the SDK methods, the reason for an SDK is that you expect it to handle stuff)
Create App registration -> immediate
Create Service Principal -> 4 retries needed before succeeded, a total of around 17s wait
GetOwners (to see what new owners would need to be added) -> Fails again with same error. So would need another retry mechanism here and at any other call that might happen. That would mean processing an entire app registration definition goes from 1 or 2 seconds to 1 minute or more...
jeromekol commentedon May 7, 2026
same for us, we have:
Create app => works always
Create Service Principal for App => fails always and immediate retries for ~15 seconds did not do the trick.
Create App role Assignment for SP on another SP => fails again, another retries needed.
We depend now that the calling clients of our API have retry mechanisms implemented, because the call duration changed from ~5s to >30s. I've made the observation if you fail fast on the retries and do a fresh client call (which creates a new instance of the Graph client for us), that it is more likely to succeed.
daanbroekhuizen commentedon May 7, 2026
Same scenario here, this used to work flawlessly. Experiencing the same behavior when calling the API through powershell.
We've implemented a retry mechanism now with a check to fetch if the application is created. Even when this returns true, creating the service principal fails often.
BloodSeaker commentedon May 7, 2026
And how do you decide upon retry? I only get an exception thrown, so that is the 'retry' trigger. But could also lead to retries with actual errors. Or are you parsing the message and decide based on some strings?
I contacted Microsoft through our partnership support. They said as of April 20th, the 'session consistency' was no longer supported in the graph api. Only when getting an explicit 'exclusion', it is still possible to have it up to end of May.
Also it only happens in 'applications without user'. That's why, when I debug this in visual studio, I don't experience this behavior, as there you have delegation.
daanbroekhuizen commentedon May 8, 2026
Yep, same here. In case of an exception, retry. We already had an scenario where multiple apps were created in the tenant where only 1 was required.
We save the object ID of the initial create in a separate variable. If all retries fail, in the finally we try to remove the app now to prevent 'contaminating' the AD.
We authenticate as an app, not delegated.
BloodSeaker commentedon May 8, 2026
MIchaelMainer commentedon May 11, 2026
App provisioning has always required time to complete after making a successful API call. Sometimes, the period is short enough that subsequent calls succeed.
Best way forward is to get the appid from the success response of the create call, and validate that the app "exists" before attempting to make a call that will update properties on that app. You will need to make sure that the update is fault tolerant and use a retry routine (as suggested above).
This has been a reality since the beginning of application provisioning since 2015. Unfortunately, the client lib team doesn't own the underlying API so we can't fix this. Thank you for opening this so that others can discover this scenario's explanation.
BloodSeaker commentedon May 12, 2026