The two jstests added by SERVER-128128 can fail intermittently with ShardCannotRefreshDueToLocksHeld (code 343, Routing info refresh did not complete) rather than with the behaviour they cover:

• start_or_continue_participant_failover.js
• sub_router_new_participant_records_term.js

Cause

When shard0 sub-routes the $lookup to shard1 inside the transaction and its routing info for the foreign collection is stale, it cannot refresh. On v8.0 the shard-local refresh-and-retry is one-shot, disabled for continuing transactions, requires no locks held, and is skipped for aggregates containing $mergeCursors; the router-side retry added by SERVER-58021 covers the write path only. The shard therefore aborts and the error reaches the client carrying the TransientTransactionError label.

That is the same label as the NoSuchTransaction the failover test asserts on, which is why pre-warming the catalog cache only lowers the odds rather than removing them.

Fix

Already done on the v8.0 backport branch (PR #60047, commit 8ff83b595ee):

• wrap each transaction in withRetryOnTransientTxnError from jstests/libs/auto_retry_transaction_in_sharding.js, so the whole scenario restarts with a fresh session the way a driver would;
• in the failover test, exempt NoSuchTransaction from that handling, since that abort is the result under test.

The same change needs to be applied on master, 9.0 and v8.3.