This is a follow-up from SERVER-131720.

In that ticket, I moved the "fcv transition in progress check" in ConfigsvrReshardCollection (the command to start or join resharding) to be in checkIfConflictsWithOtherInstances. This was done to fix an issue where the check caused the ConfigsvrReshardCollection command to fail before it could get and join an existing coordinator, and result in the DDL lock being released while resharding was still running.

My reasoning at the time for moving the "fcv transition in progress check" into checkIfConflictsWithOtherInstance was that it appeared to only run after primary only service could not find an existing instance, and is about to create a new one. But that assumption was not correct.

ConfigsvrReshardCollection creates a coordinator doc with a new random resharding uuid and passes it to getOrCreate Since the uuid is a new randomly generated one, the scan to find another coordinator instance with the same uuid fails. The checkIfConflictsWithOtherInstancess function then runs, which is what actually finds the existing instance with the same options.

As a result, the fcv transition in progress check still runs before joining an existing resharding coordinator.