batch_write_command_insert.js fails in the fcv_upgrade_downgrade_sharding_jscore_passthrough suite family (including the _retryable_writes matrix variant). The large unordered insert of maxWriteBatchSize (100k) documents fails with every op returning code 82 (NoProgressMade): "No progress was made executing write ops in after 20 rounds (21 rounds total)".

Test: batch_write_command_insert.js, assertion at line 134 ("Large batch under the size threshold should insert successfully").
Failure type: JS assertion (uncaught exception) — not a server crash, TSAN race, invariant, or fassert.

Root cause. The test targets test.batch_write_insert, an untracked (unsharded, not in the sharding catalog) collection on a 1-shard cluster, routed via mongos using only the database version.
The suite runs a background loop that continuously flips setFeatureCompatibilityVersion up/down. Each FCV transition churns the database version, so mongos repeatedly hits StaleDbVersion ("No cached info for the database test"), refreshes routing, and re-resolves the collection back to UNTRACKED. The Unified Write Executor's progress rule does not count a repeated StaleDbVersion on an already-UNTRACKED collection as productive progress, so the no-progress counter never resets and the bounded retry rounds are exhausted.

The single failing insert spun for ~81s (durationMillis:80924, ninserted:0, numInterruptChecks:276) before failing all 100k ops. This is the interaction the test's own // TODO SERVER-89461 warns about.

Sequence of operations.

• Test issues a 100k-document unordered insert against the untracked test.batch_write_insert.
• Background FCV upgrade/downgrade loop bumps the database version mid-insert. mongos sees StaleDbVersion / StaleConfig, refreshes routing, resolves UNTRACKED again.
• Retry rounds repeat without "progress"; counter hits the cap (gMaxRoundsWithoutProgress = 20).
• Batch fails with NoProgressMade (code 82); the JS assert(resultOK(result)) throws.