|
A failure in clone_catalog_data.js is primarily caused because this command is meant to be called internally. When the command is run through movePrimary, the config's opTime will be gossiped. This gossiping guarantees that a stale read can't be run against the config server. When called directly, the shard running cloneCatalogData could potentially have an outdated version of the config's opTime, meaning that the requested majority commit point could be outdated as well. If the requested majority commit point is outdated, it could allow a config secondary to return outdated collection information. This happens here, causing the destination shard to create a collection it doesn't think exists yet – thus generating a new UUID in the cloning process.
The fix for the test is to await replication (or opTime committed) before attempting to call _cloneCatalogData.
|