azure-cosmos-dotnet-v3: FeedIterator unexpectedly pre-fetches next page

Describe the bug The FeedIterator<T> fetches a page of results before it is requested. A single call of ReadNextAsync() causes two POSTs to the cosmos API, rather one.

To Reproduce Here is a sample application that illustrates the problem. Note ReadNextAsync() is only called once, but the console logs two API calls.

Expected behavior FeedIterator should only fetch pages upon request.

Actual behavior FeedIterator seems to be calling for a second page of results on its own. If this is by design, then I think it is flawed, as it makes a huge assumption that we care to get more than the number of items requested.

Environment summary SDK Version: 3.4.1 OS Version: Windows 10

Additional context Here is a sample of the console’s output. Note that two POSTs occur, despite only having called ReadNextAsync() once. Also note that the contents of the second POST show the next set of results (items 5-9).

POST dbs/FeedTest/colls/Test
{"_rid":"dIVbALcqJUk=","Documents":[
  {"r":{"id":"3cc75122-20d1-4d14-ba41-c1f328d2e9f3","Index":0,"Partition":"test","_rid":"dIVbALcqJUkBAAAAAAAAAA==","_self":"dbs\/dIVbAA==\/colls\/dIVbALcqJUk=\/docs\/dIVbALcqJUkBAAAAAAAAAA==\/","_etag":"\"00000000-0000-0000-99da-8ff2d1b101d5\"","_attachments":"attachments\/","_ts":1573619207}},
  {"r":{"id":"015aa151-203a-4b85-9c7b-bd99ade327e6","Index":1,"Partition":"test","_rid":"dIVbALcqJUkCAAAAAAAAAA==","_self":"dbs\/dIVbAA==\/colls\/dIVbALcqJUk=\/docs\/dIVbALcqJUkCAAAAAAAAAA==\/","_etag":"\"00000000-0000-0000-99da-8ff4ecf101d5\"","_attachments":"attachments\/","_ts":1573619207}},
  {"r":{"id":"b74259ec-ce80-4881-931c-39355e95e23a","Index":2,"Partition":"test","_rid":"dIVbALcqJUkDAAAAAAAAAA==","_self":"dbs\/dIVbAA==\/colls\/dIVbALcqJUk=\/docs\/dIVbALcqJUkDAAAAAAAAAA==\/","_etag":"\"00000000-0000-0000-99da-8ff6345a01d5\"","_attachments":"attachments\/","_ts":1573619207}},
  {"r":{"id":"b2d53634-923c-4a54-a9f2-09ff3a4e1c97","Index":3,"Partition":"test","_rid":"dIVbALcqJUkEAAAAAAAAAA==","_self":"dbs\/dIVbAA==\/colls\/dIVbALcqJUk=\/docs\/dIVbALcqJUkEAAAAAAAAAA==\/","_etag":"\"00000000-0000-0000-99da-8ff699df01d5\"","_attachments":"attachments\/","_ts":1573619207}},
  {"r":{"id":"9555e4d7-e75f-47e2-83d3-84c1b85757bf","Index":4,"Partition":"test","_rid":"dIVbALcqJUkFAAAAAAAAAA==","_self":"dbs\/dIVbAA==\/colls\/dIVbALcqJUk=\/docs\/dIVbALcqJUkFAAAAAAAAAA==\/","_etag":"\"00000000-0000-0000-99da-8ff6dd4901d5\"","_attachments":"attachments\/","_ts":1573619207}}
],"_count":5}

POST dbs/FeedTest/colls/Test
{"_rid":"dIVbALcqJUk=","Documents":[
  {"r":{"id":"1b51b134-ef3c-4f61-b42b-486391bc2e7e","Index":5,"Partition":"test","_rid":"dIVbALcqJUkGAAAAAAAAAA==","_self":"dbs\/dIVbAA==\/colls\/dIVbALcqJUk=\/docs\/dIVbALcqJUkGAAAAAAAAAA==\/","_etag":"\"00000000-0000-0000-99da-8ff7320701d5\"","_attachments":"attachments\/","_ts":1573619207}},
  {"r":{"id":"a4d7a76d-683d-46ec-94c1-c820a3572fdf","Index":6,"Partition":"test","_rid":"dIVbALcqJUkHAAAAAAAAAA==","_self":"dbs\/dIVbAA==\/colls\/dIVbALcqJUk=\/docs\/dIVbALcqJUkHAAAAAAAAAA==\/","_etag":"\"00000000-0000-0000-99da-8ff77f7201d5\"","_attachments":"attachments\/","_ts":1573619207}},
  {"r":{"id":"189306b0-aae2-4b4f-9ff8-e0b566943fe4","Index":7,"Partition":"test","_rid":"dIVbALcqJUkIAAAAAAAAAA==","_self":"dbs\/dIVbAA==\/colls\/dIVbALcqJUk=\/docs\/dIVbALcqJUkIAAAAAAAAAA==\/","_etag":"\"00000000-0000-0000-99da-8ff7cf4e01d5\"","_attachments":"attachments\/","_ts":1573619207}},
  {"r":{"id":"348cf465-de43-420e-9c30-11116dc4a755","Index":8,"Partition":"test","_rid":"dIVbALcqJUkJAAAAAAAAAA==","_self":"dbs\/dIVbAA==\/colls\/dIVbALcqJUk=\/docs\/dIVbALcqJUkJAAAAAAAAAA==\/","_etag":"\"00000000-0000-0000-99da-8ff81b2101d5\"","_attachments":"attachments\/","_ts":1573619207}},
  {"r":{"id":"297d734e-ba44-409b-8c0c-95c44aa13983","Index":9,"Partition":"test","_rid":"dIVbALcqJUkKAAAAAAAAAA==","_self":"dbs\/dIVbAA==\/colls\/dIVbALcqJUk=\/docs\/dIVbALcqJUkKAAAAAAAAAA==\/","_etag":"\"00000000-0000-0000-99da-8ff8684101d5\"","_attachments":"attachments\/","_ts":1573619207}}
],"_count":5}

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 22 (16 by maintainers)

Most upvoted comments

No need to apologize. I should have been more clear that we had functional bug that is taking priority, and that this will get prioritized next. I’m just trying to be as transparent as possible with the reasoning behind the prioritization of fixes. We really appreciate the detailed bug report with the sample. We’ll try to get the issue fixed as soon as we can.

j82w on Nov 13, 2019

eta: 3.7.0-preview2 does not fix the issue, and neither does the custom build in the other issue

🎉 3.9.0-preview fixes my problem - reducing RU consumption back to levels as per V2 (using preview-3 now which is also healthy).

Any rough eta on when we’ll see a 4.x preview with this fix included?

bartelink on May 17, 2020

for ORDER BY queries you can now set a partition key to avoid this behavior:

https://github.com/Azure/azure-cosmos-dotnet-v3/pull/1319

bchong95 on May 16, 2020

@j82w, Sorry I do not follow your reason for why this is required.

What is the second request resolving? From the above and inspecting the responses & continuation token returned from the sdk it appears to be done to resolve the ‘rid’ and order by values of the next item for use in the continuation token?

If so could this not be done more efficiently by the sdk/cosmos requesting ‘MaxItemCount’ + 1 so the required info can be provided in the single request. Nothing else from the second request appears to be used??

Sorry if I simply do not get the issue here, I’m pretty new to using Cosmos but it does appear to be pretty wasteful & costly as is.

stephenwilson11 on Feb 26, 2020

This seems to be a bug in the way query is buffering the pages. Assigned to @bchong95 for the fix.

j82w on Nov 13, 2019