The OP_GET_MORE wire protocol message includes an "ntoreturn" field which the client can set in order to indicate the number of results it wants in the batch. A value of zero means that there is no batchSize, and a positive value sets a specific batchSize. Negative values are not meaningful, but the server is willing to accept them. (The implementation is such that the server will happen to return batches of size 1 when it receives a negative ntoreturn.) Instead, the server should return an error to the client.

Discovered because the shell will pass a negative ntoreturn with the OP_GET_MORE if the initial query has a negative limit. As far as I know this is currently only possible with a tailable cursor:

./mongo --readMode legacy
> db.c.drop();
> db.createCollection("c", {capped: true, size: 1024});
> db.c.insert({_id: 1});

// As expected, sends an OP_QUERY with ntoreturn of -20.
> var cursor = db.c.find().addOption(2).limit(-20);
> cursor.next();
{ "_id" : 1 }

// Sends an OP_GET_MORE with ntoreturn of -20 rather than +20.
> db.c.insert({_id: 2});
> cursor.next();
{ "_id" : 2 }

As part of this ticket, we should fix the shell to not send a negative OP_GET_MORE ntoreturn in this corner case.

The getMore command properly rejects negative batchSize values, so this only affects legacy OP_QUERY/OP_GET_MORE reads.