Summary

The server monitoring spec currently allows monitors to leave operations blocked in server selection after a check if the check did not change the topology. If drivers actually implement this, it can lead to undesirable behavior though:

• Server A goes down with error
• Operation comes in, fails server selection, requests a new check
• Monitor for server A performs a check
• Check fails with same error, doesn't notify topology changes
• Operation remains blocked in server selection for heartbeatFrequencyMS or server selection timeout

If monitors were to signal that the topology failed after every check, the operation would be unblocked, fail server selection again, and request a new check, allowing the topology to be rediscovered more quickly once it comes back up.

Note that the requested requirement is already implicitly required to pass the test in DRIVERS-1251.

Motivation

Who is the affected end user?

End users.

How does this affect the end user?

Operations can be blocked for a long time in the event of failover.

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

If a driver does not adhere to the above requirement, it will happen any time failover occurs.

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

In actual production cases where lots of operations are being fired off, it probably doesn't affect the user in practice. For use cases where only a few operations are being executed, it could cause blocking for 10s of seconds.

Is this issue urgent?

It's possible that no drivers are affected by this, since otherwise users would likely complain. It's still good to update the spec so drivers don't accidentally have this issue.

Is this ticket required by a downstream team?

No

Is this ticket only for tests?

No