SERVER-92847 describes a possible data loss due to the filtering metadata being initialized incorrectly. 

The initialization of the CSR took place before the sharding state was initialized, which caused the initialization to believe the node is part of a standalone replica-set and not a shard, and marked the entry as UNTRACKED instead of UNKNOWN.

The sharding protocol does not support a case scenario where the metadata for a shard owning a chunk can be incorrect. 

The checkMetadataConsistency controls the metadata consistency only in case of  index inconsistency. In the test failure that originally discovered the incorrectness, an index inconsistency was forced by an aborted migration. Without that lucky interleaving, we would never have known about this issue. 

The goal of the ticket is to extend the checkMetadataConsistency to provide that check on whether we have an index inconsistency for the shard key or not. This problem could be more general and be present in multiple parts.