Does the Cosmos .NET SDK ReadManyItemsStreamAsync() method have a batch size limitation like the other query APIs?

Question

I'm looking to use the ReadManyItemsStreamAsync() method from the Cosmos SDK for .NET to read out thousands of records from a container, and save them to a file. Streams sound great since I can just copy the response stream to the file stream and bypass unnecessary deserialization.

In the past, when working with other Cosmos APIs that query containers, we have to account for batch size limitations of the API and use an iterator pattern to check for more results and then read next "page" of results in a loop, in order to get all the results of a query beyond a single batch/page size.

However, I noticed that the ReadManyItemsStream only returns a ResponseMessage with a Content property of type Stream (to be expected), but has no concept of iterators or checking for more/reading next results, etc.

A google search of that specific method doesn't yield anything useful except the link to the MS docs. And the docs don't mention anything about batch limits, nor does the sample code hint to batch limits.

Does this mean that it will actually return a stream with all results, regardless of the size of the batch - so, if I pass in a list of like 3,000 or 15,000 document IDs, it will grab all of those in one request and return as a single stream response?

Answer 1

Deferring to source code: https://github.com/Azure/azure-cosmos-dotnet-v3/blob/master/Microsoft.Azure.Cosmos/src/Resource/Container/ContainerCore.Items.cs#L285

The ReadMany code will issue requests to the service optimizing the queries across physical partitions and once it gathered all the responses from all those individual requests per physical partition , it unifies them into a single ResponseMessage: https://github.com/Azure/azure-cosmos-dotnet-v3/blob/c6101ce292d1fe33d8aa81a1ee1a2d3407f8b1f4/Microsoft.Azure.Cosmos/src/ReadManyQueryHelper.cs#L57-L62

So no, there is no limit, the internal implementation is the one taking your input and splitting it into different requests as needed, then unifying it all into a single response where the Request Charge is equal to the sum of all the individual requests required to complete the operation, and the Content contains all the documents (could be bigger than 4Mb which would be the normal limit of a service response).