When determining whether it is possible to resume a change stream, we currently reject the resume attempt and uassert if a document observed in the stream has the same clusterTime but a different UUID than the resume token. However, in the case of the new whole-database and cluster-wide change streams running on a sharded cluster, this is a legitimate scenario; we may observe operations from multiple shards that occurred at the same time on different namespaces.

To ensure correct resume semantics, we should continue to examine subsequent documents in the stream if the current document's UUID sorts before the resume token's, implying that we should expect to see the resume token later. However, if the document's UUID sorts after the resume token's UUID, then we will never see the token and can safely reject the resume attempt.