-
Type: Bug
-
Resolution: Fixed
-
Priority: Critical - P2
-
Affects Version/s: 1.5.0
-
Component/s: None
-
None
The cursor implementation in the mongo-c-driver makes this assumption:
If the server returns a non-zero cursor id, then the cursor isn't finished because there are more documents to iterate through.
Right now, sharded clusters return a non-zero cursor id even when the document limit has been reached. So, our cursor throws an error when it gets conflicting information: The user-defined limit has been reached but the cursor id isn't zero.
Here is the command that fails (all the way back to mongo-c-driver version 1.5):
mongoc_collection_find_with_opts ( collection, bson_new(), /* filter */ BCON_NEW("limit", BCON_INT64(2), "batchSize", BCON_INT64(2)), /* other options */ NULL);
Here is the assertion that fails when the command is ran:
int64_t remaining = limit - cursor->count; BSON_ASSERT (remaining > 0);
I attached an example-client.c file that can be ran to reproduce the bug.
- is related to
-
PHPC-1251 Upgrade libmongoc to 1.12.0
- Closed
-
SERVER-21086 mongos does not kill cursor with getMore command when batch size gets you exactly to the limit
- Closed