azure-sdk-for-js: Most Track 2 SDKs do not actually support paging

  • Package Name: Most of them
  • Package Version: Track 2
  • Operating system: All
  • nodejs
    • version: 14
  • browser
    • name/version:
  • typescript
    • version: 4.5
  • Is the bug related to documentation in

Describe the bug Most of the Track 2 SDKs don’t actually seem to support paging in their implementation of PagedAsyncIterableIterator.

To Reproduce Steps to reproduce the behavior:

  1. As an example, using @azure/arm-resources, get a resource management client.
  2. Call e.g. resourceClient.resourceGroups.list().byPage({ maxPageSize: 5 })
  3. Get back 60 resource groups in the first “page” (which is all of them)

Expected behavior Need pages to contain at most maxPageSize items, and provide a continuation token to get the subsequent pages

Additional context Following along with the above example, the byPage method does not even use the argument passed to it: https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/resources/arm-resources/src/operations/resourceGroups.ts#L66

Additionally, the return result is ResourceGroup[] and no continuation token is provided.

We have noticed this issue on most of the packages we’ve looked at. A notable exception is @azure/storage-blob, presumably because of https://github.com/Azure/azure-sdk-for-js/issues/15868#issuecomment-932455408.

For some context, our use cases are in the Azure extensions for VSCode. We need to have paging that is advanced manually for the sake of user experience. Our prior behavior was to load 25 or 50 (depending on scenario) at a time, with a “Load more…” button to grab the next page.

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 4
  • Comments: 21 (11 by maintainers)

Most upvoted comments

@lirenhe The feature requested is an improvement to pageable operations. Pageable operations return an object that has a byPage method which returns an iterator over pages of results. byPage takes an options bag as input but currently it is being ignored in management-plane libraries and the request is to support that options bag properly. The options include one for specifying the maximum number of elements in a page.

@deyaaeldeen I will prioritize this issue and start working on it next week. I will release a new version shortly after that.

I just tried the above sample. The first page of five came through successfully, but then it threw an error on the next iteration (code InvalidTopInQueryString):

RestError: The value for top of '5,5' is not an integer; the value must be an integer value greater than zero.
    at handleErrorResponse (d:\\vscode-docker\\dist\\extension.bundle.js:75695:19)
    at deserializeResponseBody (d:\\vscode-docker\\dist\\extension.bundle.js:75630:45)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)

In your description though it suggests top is used to control page size, rather than PageSettings.maxPageSize as is passed in to byPage() (and ignored due to https://github.com/Azure/autorest.typescript/issues/1199).