Summary

The latest 9.0 release intentionally can delay opening a current-time change stream for correctness (SPM-1941). The effects of this is that a (all node) cluster change stream can't emit its initial resume token (postBatchResumeToken) until the config server's cluster time advances past the start time, and in an idle cluster the only thing that advances the cluster time is the periodic noop periodicNoopIntervalSecs which is 1 on config servers and might be tunable.

This is causing evergreen failures for drivers that have implemented CSOT, but would be relevant to any driver capable of applying maxTimeMS < 1s (config server's periodicNoopIntervalSecs) to a changeStream aggregation command.

Motivation

Who is the affected end user?

Drivers

How does this affect the end user?

N/A

How likely is it that this problem or use case will occur?

Always on 9.0+ sharded clusters

If the problem does occur, what are the consequences and how severe are they?

C/I failures

Is this issue urgent?

Require to unskipped CSOT tests

Is this ticket required by a downstream team?

NA

Is this ticket only for tests?

Yes

Acceptance Criteria

Extend the unified test format to include a runner option for advancing the config server's cluster time immediately before opening a change stream.