You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug In short: Get-AzOpsRoleEligibilityScheduleRequests should have retry capability.
Bit longer:
We are using Federated Workload Identity for executing our AzOps Pull pipeline executing the Invoke-AzOpsPull method. Because of the size of our environment, we need to do periodical reauthentication in the background for the identity, because of it's limited token validity time frame.
We experienced that during our reauthentication actions, the Get-AzOpsRoleEligibilityScheduleRequests function throws terminating error caused by temporal token invalidity.
The reason of the temporal token invalidity lies in the fact that during reauthentication, the previously used accessTokens got invalidated, and till we get the new accessToken, some calls Get-AzRoleEligibilityRequest/Get-AzRoleEligibilityScheduleRequest calls are still going out in in the foreground.
The calls with these errors should be retried, as they are in multiple places in AzOps.
Steps to reproduce
I think there is no easy way to reproduce this because of multiple reasons, (High scale env where PULL runs for multiple hours, FWI as executor with periodic reauthentication) but something like this may can do the trick:
Start a background task where you are reauthenticating with Disconnect/Connect-AzAccount after some sleep
Execute Invoke-AzOpsPull with -skipPim = $false
Screenshots
[Get-AzRoleEligibilitySchedule : [ClientAssertionCredential authentication failed: A configuration issue is preventing authentication - check the error message from the server for details. You can modify the configuration in the application registration portal. See https://aka.ms/msal-net-invalid-client for details. Original exception: AADSTS700024: Client assertion is not within its valid time range. Current _<{hidden}>_, assertion valid from _<{hidden}>_, expiry time of assertion _<{hidden}>_. Review the documentation at https://learn.microsoft.com/entra/identity-platform/certificate-credentials . Trace ID: _<{hidden}>_ Correlation ID: _<{hidden}>_ Timestamp: _<{hidden}>_
At line:31 char:13�[0m
+ $roleEligibilitySchedules = Get-AzRoleEligibilitySchedule …�[0m
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~�[0m
+ CategoryInfo : NotSpecified: (:) [Get-AzRoleEligibilitySchedule_List], AuthenticationFailedException�[0m
+ FullyQualifiedErrorId : Microsoft.Azure.PowerShell.Cmdlets.Resources.Authorization.Cmdlets.GetAzRoleEligibilitySchedule_List�[0m
##[error]PowerShell exited with code '1'.
##[section]Finishing: Initialize
The text was updated successfully, but these errors were encountered:
Describe the bug
In short: Get-AzOpsRoleEligibilityScheduleRequests should have retry capability.
Bit longer:
We are using Federated Workload Identity for executing our AzOps Pull pipeline executing the Invoke-AzOpsPull method. Because of the size of our environment, we need to do periodical reauthentication in the background for the identity, because of it's limited token validity time frame.
We experienced that during our reauthentication actions, the Get-AzOpsRoleEligibilityScheduleRequests function throws terminating error caused by temporal token invalidity.
The reason of the temporal token invalidity lies in the fact that during reauthentication, the previously used accessTokens got invalidated, and till we get the new accessToken, some calls Get-AzRoleEligibilityRequest/Get-AzRoleEligibilityScheduleRequest calls are still going out in in the foreground.
The calls with these errors should be retried, as they are in multiple places in AzOps.
Steps to reproduce
I think there is no easy way to reproduce this because of multiple reasons, (High scale env where PULL runs for multiple hours, FWI as executor with periodic reauthentication) but something like this may can do the trick:
Screenshots
The text was updated successfully, but these errors were encountered: