Related command
az graph query
Is your feature request related to a problem? Please describe.
Repeatedly getting throttled when using az graph query on large deployments. Have had the limits increased on my service principal, but still getting throttled. Relates to MS Enterprise support ticket #2407220030002618
Describe the solution you'd like
When using az graph query and a throttle limit is reached, slow down the CLI response until it is under the limit. Current behaviour is to hit the limit and return an error - we would prefer that the response was slowed down instead.
Describe alternatives you've considered
It would be hard to split out the principals, as many resources have cross-subscription permission dependencies (e.g. resource A in subscription 1 has permissions on resource B in subscription 2 which has permissions on resource C in subscription 3 etc.). Also, ultimately there would be the same net number of queries on the graph.
We've also considered implementing retry logic to look for a throttling error on CLI - messy!
Additional context
Affects our large deployments across many subscriptions. There are other resources in the Azure management plane (e.g. setting SQL firewalls ) that will just slow down the Azure CLI operations transparently to the user when some throttling limit is reached, and each CLI operation on this resource will just be slow until the throttling eases. We would expect az graph query to operate the same way (with an optional flag added to cancel the query instead of throttle), but instead it just errors out when the throttling limit is reached.
Related command
az graph queryIs your feature request related to a problem? Please describe.
Repeatedly getting throttled when using
az graph queryon large deployments. Have had the limits increased on my service principal, but still getting throttled. Relates to MS Enterprise support ticket #2407220030002618Describe the solution you'd like
When using
az graph queryand a throttle limit is reached, slow down the CLI response until it is under the limit. Current behaviour is to hit the limit and return an error - we would prefer that the response was slowed down instead.Describe alternatives you've considered
It would be hard to split out the principals, as many resources have cross-subscription permission dependencies (e.g. resource A in subscription 1 has permissions on resource B in subscription 2 which has permissions on resource C in subscription 3 etc.). Also, ultimately there would be the same net number of queries on the graph.
We've also considered implementing retry logic to look for a throttling error on CLI - messy!
Additional context
Affects our large deployments across many subscriptions. There are other resources in the Azure management plane (e.g. setting SQL firewalls ) that will just slow down the Azure CLI operations transparently to the user when some throttling limit is reached, and each CLI operation on this resource will just be slow until the throttling eases. We would expect
az graph queryto operate the same way (with an optional flag added to cancel the query instead of throttle), but instead it just errors out when the throttling limit is reached.