As part of Authoritative Shards, setFCV clones the authoritative DB/collection metadata from the config server to the shards. This is done by having the config server spawn the cloning DDL coordinator on the shards during its kUpgrading transitional FCV.

The expectation is that the recipient shards are also in kUpgrading. This happens during the "happy path" however there is an interleaving where this does not happen:

1. setFCV starts a FCV upgrade to 9.0
2. During the kPrepare phase (configsvr+shardsvrs on kUpgrading FCV), we clone the authoritative metadata from the configsvr to the shards.
3. The config server enters the kComplete phase and sends the shards to FULLY UPGRADED 9.0 FCV.
4. However right before the config server goes to FULLY UPGRADED 9.0 FCV, it steps down.
5. The setFCV upgrade to 9.0 is retried. This re-executes all the (kStart, kPrepare, kComplete) phases.
6. During the re-execution of kPrepare phase, we re-send the clone authoritative metadata to the shards, despite the shards already being in FULLY UPGRADED 9.0 FCV.

Note that with Symmetric FCV this does not happen (since SERVER-119476, in steps 5-6 we would resume the upgrade from the kComplete phase without re-executing kPrepare).

This also means that the problematic interleaving can not currently be hit in any of the EVG variants.

We should either:

• Assume a dependency on Symmetric FCV & close this ticket without action, or
• Add a workaround to handle this case (e.g. do nothing in the cloning DDL coordinator if it runs with OFCV=9.0).