[CDRIVER-3251] Do not send an extra getMore when resuming if aggregate returns an empty batch Created: 18/Jul/19  Updated: 27/Oct/23  Resolved: 23/Sep/19

Status: Closed
Project: C Driver
Component/s: libmongoc
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Kevin Albertson Assignee: Samantha Ritter (Inactive)
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related

 Description   

When resuming change stream, we call mongoc_cursor_next on the cursor we create with the aggregate command. But if the aggregate returned an empty batch, we mongoc_cursor_next will send another getMore command (but we should just return NULL in that case).



 Comments   
Comment by Jeremy Mikola [ 23/Sep/19 ]

samantha.ritter, jeff.yemin: IIRC, this issue relates somewhat to PHPLIB-451. I think the scenario common to both
C and PHPLIB is that we want to advance to the first result within the batch (if any) after either the initial aggregate or a resuming aggregate, without ever sending a superfluous getMore command. To address that, I tracked whether aggregate returned an empty firstBatch or not to decide if it was safe to call mongoc_cursor_next() without the risk of triggering a getMore.

What portion of the spec mandates an "extra" getMore and prohibits the above?

Comment by Samantha Ritter (Inactive) [ 23/Sep/19 ]

The spec tests for change streams mandate that we send this "extra" getMore after the aggregation.  For some drivers' cursor implementations, where calling next() on the cursor may loop and wait for documents to become available, this makes more sense.  For the C driver, the "extra" getMore right after a successful aggregation that returns an empty batch feels a bit superfluous, but it is spec-defined behavior.  Closing this ticket "Works as Designed."

Generated at Wed Feb 07 21:17:31 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.