Summary

The unified test runner specification includes the following guidance:

If the test might execute a `configureFailPoint` command, for each target client the test runner MAY specify a reduced value for `heartbeatFrequencyMS` (and `minHeartbeatFrequencyMS` if possible) to speed up SDAM recovery time and server selection after a failure; however, test runners MUST NOT do so for any client that specifies `heartbeatFrequencyMS` in its `uriOptions`.

As of SERVER-128517, the server enforces a minimum heartbeat frequency of 500ms for streaming hellos. This means that minHeartbeatFrequencyMS can no longer be set lower than 500ms without setting the minWaitForStreamingHelloMillis server parameter.

Motivation

Who is the affected end user?

Drivers engineers writing tests.

How does this affect the end user?

Depending upon test behavior, timeouts or unexpectedly slower tests.

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

Only when minHeartbeatFrequencyMS is overridden in tests.

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

Unexpected behavior in tests.

Is this issue urgent?

No.

Is this ticket required by a downstream team?

No.

Is this ticket only for tests?

Yes.

Acceptance Criteria

One of the following:

• Remove all language about overriding minHeartbeatFrequencyMS for tests in the specifications.
• Amend the orchestration configurations to set minWaitForStreamingHelloMillis to 0.
• Add guidance for drivers to set minWaitForStreamingHelloMillis at runtime in tests.

Proposed choice: option 1. Setting minWaitForStreamingHelloMillis is invalid on older server versions, which would add complexity for options 2 and 3.