At aggregation planning time, we should acquire the appropriate locks and assert that there exists a unique index that contains all of the fields on the uniqueKey (where order of the fields does not matter).

If the uniqueKey is the document key, we must elide the check. The "document key" is

• the _id for an unsharded collection
• the _id and all the fields of the shard key for a sharded collection

If the output collection is sharded, the uniqueKey must contain all of the fields of the shard key, and there must exist a unique index containing exactly the remaining fields. For example, for a collection sharded on {x: 1} and a uniqueKey {x: 1, y: 1, z: 1}, we must enforce the existence of a unique index containing exactly the fields "x", "y" and "z" (in no particular order).

This work should already be done for unsharded collections in SERVER-36424, this ticket represents the work to make this happen when the target collection is sharded.