Summary

Currently the unified format specifies an optional runOnRequirement of auth:boolean where true implies basic SCRAM auth is enabled in order to run the test in an environment where drivers will send saslStart/saslContinue messages. However, there are alternative mechanisms that do not use those messages in their handshakes but still could be considered valid for an "auth:true" environment. We should consider adding an additional authMechanism property or extending the type of auth:boolean | string, to accept a mechanism to allow further specificity.

Motivation

Who is the affected end user?

All driver's that implement the unified test runner.

How does this affect the end user?

Currently there are tests related to load balancer, and soon retryablity that rely on the "convenient" scenario of making saslContinue fail in order to get handshakes to fail for operations but not for monitoring connections. It would be more future proof to make these test specify precisely which mechanism they need to get this behavior.

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

It depends on future auth tests being converted to the unified format.

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

It could lead to custom logic being implemented in every runner, as opposed to building it into the format spec.

Is this issue urgent?

No, and the addition would conceivably be a small spec/schema change that would bump the version for tests that use this feature.

Is this ticket required by a downstream team?

No.

Is this ticket only for tests?

Yes

Acceptance criteria

• Discuss the best path (auth takes string, or new authMechanism prop)
• Bump the schema version with the new change
• search for existing tests that use SCRAM related failPoints and bump their schema version to ensure they remain forward compatible