If a shard key is refined (using refineCollectionShardKey) to include a nested field (e.g. key {a: 1} is refined to be {a: 1, "b.c": 1}), the resulting chunk boundaries will include nested documents, which is not a valid format.

This causes future metadata refreshes to fail, with shard primaries logging "Error refreshing cached collection" messages like:

{"t":{"$date":"2020-09-03T14:16:18.513-07:00"},"s":"I",  "c":"SH_REFR",  "id":24103,   "ctx":"ConfigServerCatalogCacheLoader-10","msg":"Error refreshing cached collection","attr":{"namespace":"XXX.XXXX","durationMillis":2,"error":"ConflictingOperationInProgress: Not all elements of { i: MinKey, j: MinKey, k: { nested: MinKey } } are of type minKey"}}

refineCollectionShardKey should create boundaries with dotted field names instead of nested documents.

It is possible to manually correct chunk and zone range metadata, but currently the best course of action is to avoid using refineShardKey to incorporate a nested field into the shard key.

A test refining the shard key with a new dotted field has temporarily been commented waiting for this issue to be addressed.