SERVER-92276 improved batch write operations which are not ordered and have a mix of operations that target a single shard and operations that target multiple shards, by batching together all the operations that target the same single shard and then coming back to process the rest of operations (code).

When each batch is executed there is check in debug builds that the estimated size of the batch is greater than the actual size of the batch (code). The size of each batch is the sum of the size of all writes in the batch (code) and the size for each write is computed using a getWriteSizeFn method (code). In getWriteSizeFn method the size of the first write in a batch accounts for the nsInfo (code) while the rest of the writes in the same batch do not. The problem is that if we encounter a write that targets multiple shards, i.e. shard0 and shard1, before we encounter a write that targets a single shard e.g shard0 then the nsInfo for shard0 is accounted in this write which is not processed at this point. Thus, the estimated size for the batch targeting shard0 is smaller than it should be.

This is the scenario in deleteOne_without_shard_key_basic.js. The first operation targets shard0 and accounts for nsInfo, the second operation targets both shard0 and shard1, the size of nsInfo for shard1 is added in this write but this write is not added in the batch for shard1 since it targets more than one shards. The third operation targets shard1 but does not account for nsInfo since this has been already done. Thus, at the end the estimated size for shard1 is smaller than the actual batch size.

Moving the decision as to whether a write can be processed in the current batch before we estimate the size of the write can solve this issue.