Azure-cli: in `az group deployment list`, the --top parameter is ignored
Describe the bug
In az group deployment list, all results are returned no matter the value of the --top parameter.
To Reproduce
Create a resource group test with more than one deployment. Run az group deployment list -g test --top 1.
Expected behavior
Exactly one deployment should be returned.
Environment summary
Azure CLI version 2.0.61, Bash on Windows.
Additional context
The top parameter _is_ checked for errors (must be positive).
A workaround is to pass the returned JSON through jq '.[0:<limit>]', but that has a performance penalty, in that all results are still returned, even if most are discarded.
midgleyc
All 2 comments
The correct values are being sent to the service. It simply does not correctly use them (or rather, at all, it seems). Given that, there is nothing we can do in the CLI that's any better than your jq query. We will escalate this issue to the appropriate service team.
tjprescott
on 2 Apr 2019
@midgleyc - I looked into this just now since the behavior still exists. The issue is not the result of the ARM API itself, which correctly respects the top parameter (I checked this on all of the stable API releases in 2019 and 2020 via Postman). We will work with the SDK teams to get this addressed.
It was annoying me why this was happening, so I investigated:
tl;dr: A list deployments call returns a nextLink property, which the Python SDK consumes to make further consecutive calls. This behavior is intentional for situations when the response can be long. In the case of a top parameter being supplied, the nextLink property _usually_ won't need to be consumed (explained further below).
Same explanation as above (but with links to code): When you run az group deployment list, the following azure-cli code is run. That code calls the following Azure Python SDK code for Deployment Operations which correctly passes in the top parameter BUT it consumes the nextLink property via ItemPaged to make additional requests (regardless of what the value of top is).
@tjprescott - The solution I propose is to make the following change in the Azure Python SDK:
On the first request to list deployments, _If_ the size of the response is equal to top, we're done (this covers most scenarios). _Otherwise_, we should continue to make requests to nextLink (as the current code does) until the total accumulated response size is equal to top.
snaheth
on 31 Aug 2020
Related issues
dhermans
路
3Comments
troydai
路
3Comments
williexu
路
3Comments
oakeyc
路
3Comments
seanknox
路
3Comments
Most helpful comment
@midgleyc - I looked into this just now since the behavior still exists. The issue is not the result of the ARM API itself, which correctly respects the
topparameter (I checked this on all of the stable API releases in 2019 and 2020 via Postman). We will work with the SDK teams to get this addressed.It was annoying me why this was happening, so I investigated:
tl;dr: A list deployments call returns a
nextLinkproperty, which the Python SDK consumes to make further consecutive calls. This behavior is intentional for situations when the response can be long. In the case of atopparameter being supplied, thenextLinkproperty _usually_ won't need to be consumed (explained further below).Same explanation as above (but with links to code): When you run
az group deployment list, the following azure-cli code is run. That code calls the following Azure Python SDK code for Deployment Operations which correctly passes in thetopparameter BUT it consumes thenextLinkproperty viaItemPagedto make additional requests (regardless of what the value oftopis).@tjprescott - The solution I propose is to make the following change in the Azure Python SDK:
On the first request to list deployments, _If_ the size of the response is equal to
top, we're done (this covers most scenarios). _Otherwise_, we should continue to make requests tonextLink(as the current code does) until the total accumulated response size is equal totop.