Overview

The JS tests resharding_retryable_writes.js and reshard_timeseries_retryable_writes.js test minimumOperationDurationMS behavior by setting it to 30,000ms and asserting that at least that much wall-clock time has elapsed before the resharding coordinator transitions to the "applying" state. This makes tests slow (minimum 30s per run) and potentially flaky.

Background

The propagation of minimumOperationDurationMS from coordinator to recipient, and the recipient waiting before transitioning to "applying", is already covered deterministically by unit tests using a mock clock. There is no need to duplicate this with real wall-clock timing in JS integration tests.

Scope of Work

• jstests/sharding/resharding_retryable_writes.js — remove timing dependency
• jstests/sharding/resharding_timeseries/reshard_timeseries_retryable_writes.js — remove timing dependency

Acceptance Criteria

• The wall-clock timing assertion (assert.gt(elapsed, minimumOperationDurationMS - epsilon)) is removed
• Test behavior is verified deterministically using an existing failpoint or resharding metrics (e.g. clone duration) — no new failpoints should be added
• Tests complete well under 15 seconds

Technical Notes

• Use a small value (1–5 seconds) of minimumOperationDurationMS if metrics-based verification is chosen
• Do not introduce new failpoints; use only existing ones if this approach is taken