[FEATURE REQUEST] Add listing overload to accept continuation token

Query/Question I’m upgrading the storage SDK in my application from v8 to v12. In v8, there is a list blobs API which accepts a continuation token and gets the next page of blobs. However, in v12, I could not find a similar API and either I need to always get the first page of blobs and use the response iterable to list using the continuation token (as shown below) or preserve the response object to avoid listing the first page every time. Is there a better way? With the first approach, I’m making unnecessary requests and with the second one, I cannot preserve state and resume processing of blobs from where I left off or continue processing on a different machine.

PagedIterable<BlobItem> response = containerClient.listBlobs();
Iterable<PagedResponse<BlobItem>> desiredPage = response.iterableByPage(continuationToken);

Why is this not a Bug or a feature Request? NA

Setup (please complete the following information if applicable):

• OS: Linux
• IDE : IntelliJ
• Version of the Library used: 12.0.0

Information Checklist Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

• Query Added
• Setup information Added

[rickle-msft]

We caught it while looking into the behavior as a part of this thread, so thanks for starting easy on us 😃

I’m not sure this will make into the next release, but I will prioritize investigating this overload and stay on top of the eager iterator behavior and keep you updated.

[SukruthKS]

While they say it is lazy, we are noticing that it only seems to be lazy insofar as waiting to call next to start, and after that it will eagerly fetch until the end of the stream, which means this iterable will try to eagerly list all your blobs, and that will be a problem. This is being tracked in #6518, and we are discussing a different implementation that will also lazy fetch as well as lazily subscribe.

Good that you caught this! It was definitely going to be an issue for us as some of the containers we list can contain a very large number of blobs.

I also hear what you’re saying about the overload to accept the continuation token rather than passing it into the return type. With your permission, I’d like to rename this issue to track adding the overload and allow #6518 to track the iterator behavior.

Sure, please go ahead.