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.