The ReshardingDonorOplogIterator intentionally doesn't return the op='n' final resharding oplog entry. Not returning the final resharding oplog entry ensures the recipient, when resuming, would be guaranteed to come across the oplog entry again in its local oplog buffer and realize it had already finished applying all of the oplog entries.

However, the current behavior leads the number of oplog entries fetched to always be greater than the number of oplog entries applied, even when resharding completes successfully. This is due to how the op='n' final resharding oplog entries are accounted for in the number of oplog entries fetched, but are not accounted for in the number of oplog entries applied. Incrementing the in-memory counter by 1 for the number of oplog entries applied when ReshardingOplogApplier::_currentBatchToApply is empty would correct this discrepancy. The on-disk value for 'numEntriesApplied' in the progress_applier collection must not be incremented by 1.