The ServiceStateMachine will implement the server side of the exhaust cursor OP_MSG protocol.

• After receiving a getMore command and running command processing, the ServiceStateMachine will check the reply message before sending it to the client.
• If the result has an error, or a cursor ID of 0 or an empty namespace, or either of those fields does not exist or is corrupt, the reply message will be sent normally without the moreToCome bit set.
• If the result is OK and has both valid cursor ID and namespace, the reply message will be sent with the moreToCome bit set.  The ServiceStateMachine will synthesize an OP_MSG with a getMore the same as the original getMore it was sent (including the exhaustAllowed bit), only with an ID the same as the ID of the reply.  This will result in getMore command processing being run again, and another reply being sent to the client. This reply will appear to be a reply to the previous reply.

Example: client sends a getMore with cursorId 9 for collection “mydb.mycoll” with 3 documents:

opCode: OP_MSG
requestId: 1
responseTo: 0 (not used for messages from client)
flagBits: exhaustAllowed
body: {
	getMore: 9,
	batchSize: 2
}

Server sends first response:

opCode: OP_MSG
requestId: 1001
responseTo: 1
flagBits: moreToCome
body: {
	ok: 1,
	cursor: {id: 9, ns: “mydb.mycoll”}
}
documentSequence: [doc1, doc2]

Since there are more documents, the server runs the getMore again and sends the response:

opCode: OP_MSG
requestId: 1002
responseTo: 1001
flagBits: 0
body: {
	ok: 1,
	cursor: {id: 0, ns: “mydb.mycoll”}
}
documentSequence: [doc3]

Because the cursor was exhausted, the moreToCome flag was not set and the cursor ID was 0.