Cursor read errors on mongod are recorded by stamping the error code on the ClientCursor, so that the query stats entry written when it is disposed attributes the failure to the query shape.
 
This does not work for the last getMore of a cursor's life. When a getMore exhausts its cursor, acquireLocksAndIterateCursor() deletes the cursor as it returns, and ClientCursor::dispose() writes the shape's entry at that moment, as a success. Anything that throws afterwards (in production, only the linearizable read concern wait in
GetMoreCmd::Invocation::run()) returns an error to the client with no cursor left to record it on, so the entry is recorded as a success in query stast.

The flow: The mechanism checks out: exhausting getMore → shouldSaveCursor == false → respondWithId == 0 → cursorDeleter fires when acquireLocksAndIterateCursor returns → dispose() → entry written. The post-batch block then finds getCursor() == nullptr and no-ops.
 
Excluded from SERVER-131927 + SERVER-131928 because while the change should be relatively small, it's on writeQueryStats(), a common path for many mongod + mongos commands.