msgraph-sdk-powershell
msgraph-sdk-powershell copied to clipboard
Get-MgIdentityGovernanceAppConsentRequest (almost) infinite loop since 6/3/2025 2 AM
Describe the bug
Since 6/3/2025 2 AM command Get-MgIdentityGovernanceAppConsentRequest returns (in our case) 17400 consent requests instead of 102 (information retrieved by Get-MgIdentityGovernanceAppConsentRequestCount). This is obviously a bug and is related to some underlying API change around the mentioned date.
Expected behavior
Get-MgIdentityGovernanceAppConsentRequest returns a correct number of existing admin requests instead of some random super high number.
How to reproduce
Just run Get-MgIdentityGovernanceAppConsentRequest (any version, its API related) and compare the returned number of results with Get-MgIdentityGovernanceAppConsentRequestCount
SDK Version
2.25.0
Latest version known to work for scenario above?
No response
Known Workarounds
$requestsCount = Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/v1.0/identityGovernance/appConsent/appConsentRequests/`$count"
Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/beta/identityGovernance/appConsent/appConsentRequests" | Get-MgGraphAllPages | select -First $requestsCount
Debug output
Click to expand log
```</details>
### Configuration
Name Value
---- -----
PSVersion 7.4.10
PSEdition Core
GitCommitId 7.4.10
OS Microsoft Windows 10.0.19045
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0, 5.0, 5.1, 6.0, 7.0}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
### Other information
_No response_
I am also experiencing this same issue. Any ETA on a fix?? Thank you.
I'm seeing something like this also, using the latest version of the Graph modules at the time of writing (2.28.0).
$Data = Get-MgIdentityGovernanceAppConsentRequest -All - I've seen this return 206400, 300200, 144200 and just now, 227700.
From the data returned by this command, there seems to be massive duplication. For example, there are 2063 objects with the AppDisplayName of 'n8n' but they all appear identical - app name, app id, id.
Get-MgIdentityGovernanceAppConsentRequestCount returns 924.
It seems like the population of "@odata.nextLink" is broken.
Using https://developer.microsoft.com/en-us/graph/graph-explorer with a query to https://graph.microsoft.com/v1.0/identityGovernance/appConsent/appConsentRequests I can see a value returned in "@odata.nextLink". Following that next link results in another page, with exactly the same value in "@odata.nextLink".
So, infinite loop until rate limiting / throttling kicks in and then the command exits, perhaps?
@peombwa, any thoughts please?
We are seeing this issue aswell since 20.05
I've managed to workaround this (I think) by manually specifying properties to be returned, testing this both in Graph Explorer and on the command line:
Get-MgIdentityGovernanceAppConsentRequest -All -Property appDisplayName, appId, id
https://graph.microsoft.com/v1.0/identityGovernance/appConsent/appConsentRequests?$select=appDisplayName,appId,id
The @odata.nextLink seems to work with this approach.
Great find @robinmalik ! - Inspired by that i tried arround a bit more and found another workarround: ~You can also specify -Top 100 (which is the default anyway) which results in the exact same behavior of the endpoint to before it got buggy.~
EDIT: I overlooked that in the GraphSDK -Top overwrites the -All Flag so when using the PowerShell GraphSDK you can't use this workarround - It should work in the c# SDK though and it certainly does when directly communicating with the Endpoint (see remark below)
In graph explorer with $top=100 and it worked there.
For PowerShell to work with you need to use a arbitrary filter ($filter=1 eq 1 -> evaluates always to true)
So the drop in workarround would be:
Get-MgIdentityGovernanceAppConsentRequest -All -Filter "1 eq 1"
[!NOTE] This is not a fix - just a workarround - the standard endpoint is still bugged out.
Btw there is also a thread open in the GraphAPI feedback portal: https://feedbackportal.microsoft.com/feedback/idea/2e282021-584b-f011-a2da-7c1e52e6fdbb
I have posted the workarrounds there aswell
Thank you for providing workarounds for this issue. Let us know if you still see this issue.
@MIchaelMainer unfortunately yes - our ticket with microsoft was archived with the information a fix will be coming before the end of the year - so let's see :)