ReshardingMetricsNew tasserts that the start time was written down for the resharding operation, but writing down the start time is new behavior. It's possible that the resharding operation began in an older version where the start time was not written down and is currently in the process of upgrading to this newer version. This tassert should therefore not trigger while upgrading or downgrading.

However, because resharding operations are aborted after sending the request to finalize the FCV version on the shards when upgrading, it is possible that a resharding recipient will update its FCV to its final value (i.e. isUpgradingOrDowngrading() is false) prior to aborting. It is therefore not possible to differentiate a resharding operation that has upgraded to the latest version since the beginning from one that has been the latest version throughout. For this reason, the resharding operations should be aborted first.

Furthermore, the resharding command currently ensures that the FCV cannot change while setting up the coordinator. However, it does not check to make sure that the current FCV is not currently in an upgrading or downgrading state. This allows for the possibility for a new resharding operation to begin during an FCV upgrade, after resharding operations are aborted, but before the shards complete the FCV upgrade (after making the above change to abort first), meaning that the operation could run across FCVs without being aborted. As such, the reshard command should fail if the current FCV is either upgrading or downgrading.

In summary, the changes above should guarantee that 1. resharding operations cannot begin during an FCV upgrade or downgrade and 2. during an FCV update, resharding operations will always be finished aborting before reaching the target FCV.