Issue on subsequent request after creating application

[BloodSeaker]

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_

[jeromekol]

we also have the same issue since a week. Using the REST API directly, does not seem to suffer from that problem.

[BloodSeaker]

we also have the same issue since a week. Using the REST API directly, does not seem to suffer from that problem.

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]

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]

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.

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]

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.