We return an error on the primary if we detect mixed schema data in a document. See code.

The issue with this check is that we cannot guarantee that a node will ever be primary when scanning any problematic documents. Consider the following scenario:

• Node 1 is primary, Node 2 is secondary
• Node 1 replicates a startIndexBuild oplog entry, and both Node 1 and 2 start a collection scan
• Node 2 scans a mixed-schema document, but does not report an error because it is secondary
• A leadership change happens and Node 2 becomes primary, Node 1 becomes secondary
• Now Node 1 scans a mixed-schema document

In this scenario, neither node reported an error about a mixed-schema document because neither node was primary when this document was scanned.

We have to follow the same approach we do with all constraint violations, which is record them on all nodes and have the committing primary confirm whether these violations still exist, and handle them at commit time.

This can cause CannotCreateIndex to escape from the index build which is not allowed.