A secondary which steps up to be primary won't necessarily have loaded the collection metadata for temporary resharding collection. This can lead assertCanExtractShardKeyFromDocs() to throw a NamespaceNotSharded exception when the ReshardingOplogApplier attempts to write to the temporary resharding collection.
The ReshardingCollectionCloner and ReshardingOplogApplier rely on assertCanExtractShardKeyFromDocs() to ensure an update doesn't write an invalid shard key value (e.g. an array value) under the new shard key pattern. We must either
- (a) ensure the collection metadata for the temporary resharding collection has been loaded before the ReshardingCollectionCloner or ReshardingOplogApplier attempt to write to it, or
- (b) retry in ReshardingCollectionCloner and ReshardingOplogApplier on the exception thrown by assertCanExtractShardKeyFromDocs(), or
- (c) move the checks into ReshardingCollectionCloner and ReshardingOplogApplier directly, and allow unversioned (direct) writes to the temporary resharding collection if they are being performed by an internal (system) Client.