Problem

jstests/sharding/query/change_streams/change_stream_future_start_time_new_shard.js fails intermittently on continuous config server stepdown suites (e.g. sharding_csrs_continuous_config_stepdown_4, enterprise-rhel-83-s390x) with:

1 is not less than 0 : Test setup invalid: cluster time already past future start time { "currentClusterTime" : Timestamp(1785789022, 14), "futureStartTime" : Timestamp(1785789015, 0) }

Root Cause

The test picks futureStartTime = now + kFutureOffsetSecs (30s), then performs addShardToCluster() and moveChunk() as test setup before verifying that real elapsed time hasn't already consumed the 30s budget. Under continuous config server stepdown, the repeated config server primary stepdowns force retries/backoff on the addShard and moveChunk config server round trips, so setup alone can take longer than 30 seconds. By the time the test reaches its own timing-guard assert, currentClusterTime has already passed futureStartTime, and the assert (correctly) fails.

The test already carries incompatible_aubsan / tsan_incompatible tags with the comment "Sanitizer variants are too slow and can not add a shard within the given kFutureOffsetSecs timeframe" — the same underlying problem, just triggered by sanitizer instrumentation overhead instead of config server churn. It was never excluded from stepdown suites.