In SERVER-38413, we changed DSShardCheckResumability such that it consumes any events at the same clusterTime as the specified resume token but which sort before it. To do so, it calls the compareAgainstClientResumeToken that was previously only called by the DSEnsureResumeTokenPresent stage.

However, the applyOpsIndex logic in compareAgainstClientResumeToken still operates on the assumption that it is only called from DSEnsureResumeTokenPresent. As a result, in cases where a resume token of clusterTime T is sent to a shard whose oplog entry at time T is a multi-document transaction, the shard may incorrectly uassert on this line when it observes that the local event's applyOpsIndex is greater than the resume token's. We may also return an inaccurate result on this line if we are on a merging shard and we observe an event with the same clusterTime as the resume token but a different UUID.