Some commands (like for example, reshardCollection, refineCollectionShardKey and updateZoneKeyRange) allows the specification of a new zone to override any existing ones, however, if a user does not specify the new shard key completely in the request, the result of the command will generate a correct but surprising chunk distribution. For example, when running reshardCollection, if the original shard key was {a: 1}, we had a single chunk {min: {a: MinKey()}, max: {a: MaxKey()}} and we issue the following command:

reshardCollection: <nss>,
    key: {a: 1, b: 1},
    zones: [{
        min: {a: MinKey()},
        max: {a: MaxKey()},
        zone: 'A',
    }]

(Note how the new shard key, namely, {a: 1, b: 1} is not specified in the zones field) the system will end up generating two chunks:

{min: {a: MinKey(), b: MinKey()}, max: {a: MaxKey(), b: MinKey()}}
{min: {a: MaxKey(), b: MinKey()}, max: {a: MaxKey(), b: MaxKey()}}

The first chunk will preserve the data placement of the zone, but the second chunk could end up being placed in a different shard. The purpose of this ticket is to identify all possible commands with this behavior, and prevent the surprising result by forcing the user to specify the full shard key in the zone so it is not filled automatically.