This is a more general case than the one described in SERVER-34702, but it has a known solution.

Consider the following sequence of events:

• A whole-db or whole-cluster change stream is opened and returns some change stream entries for updates. These notifications include the shard key.
• Two operations happen on different shards at the same cluster time. At least one of these operations is an insert.
• A collection is dropped.
• The change stream is resumed using the update event's resume token.
• When processing the insert notification which has the same cluster time as another change, the change stream machinery does not know what the shard key is for the collection, so only includes the _id in the resume token.
• This change will now have a practically arbitrary order with the other change at the same cluster time. If that change was also an insert, they will be compared by _id. It's possible that the two inserts have the same _id and the same cluster time.

One suggested approach for this problem is to remember the shard key that was given to us in the resume token when we resume, allowing us to populate the shard key for the insert entry. This will solve this scenario, but will not solve the scenarios described in SERVER-34702.