SERVER-62419 fix recover_multiple_migrations_on_stepup.js execution in config stepdown suites.

(cherry picked from commit 175fd99112a85255094c8951db61306eb802326a)

1 files changed, 3 insertions, 4 deletions

diff --git a/jstests/sharding/recover_multiple_migrations_on_stepup.js b/jstests/sharding/recover_multiple_migrations_on_stepup.js
index b8cf4644df8..03095e58864 100644
--- a/jstests/sharding/recover_multiple_migrations_on_stepup.js
+++ b/jstests/sharding/recover_multiple_migrations_on_stepup.js
@@ -57,9 +57,9 @@ joinMoveChunk1();
 // Start a second migration on a different collection, wait until it persists it's recovery document
 // and then step down the donor.
 var moveChunkHangAtStep3Failpoint = configureFailPoint(st.rs0.getPrimary(), "moveChunkHangAtStep3");
-
-var joinMoveChunk2 = moveChunkParallel(
-    staticMongod, st.s0.host, {_id: 0}, null, nsB, st.shard1.shardName, false /* expectSuccess */);
+// NOTE: The test doesn't join this parallel migration to avoid the check on its outcome,
+// which is not deterministic when executed in a configsvr stepdown suite (SERVER-62419)
+moveChunkParallel(staticMongod, st.s0.host, {_id: 0}, null, nsB, st.shard1.shardName);
 
 moveChunkHangAtStep3Failpoint.wait();
 
@@ -74,7 +74,6 @@ assert.eq(2, st.rs0.getPrimary().getDB('config')['migrationCoordinators'].countD
 // Stepdown the donor shard
 assert.commandWorked(st.rs0.getPrimary().adminCommand({replSetStepDown: 5, force: true}));
 moveChunkHangAtStep3Failpoint.off();
-joinMoveChunk2();
 
 // Check that the donor shard has been able to recover the shard version for both collections.
 assert.eq(0, collA.find().itcount());