Summary

The goal is to make using causal consistency across multiple client sessions less surprising to get correct.

Motivation

Who is the affected end user?

Application developers who want to make use of the MongoDB Server's stronger consistency guarantees have a challenging time writing highly-concurrent applications correctly.

How does this affect the end user?

They get confused.

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

Unclear how often this is a problem though Max has been called on to help in three (3) separate instances. All instances were with the Golang driver but the syntax is generally the same across drivers.

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

Operations attempted on the MongoDB Server fail with an error message.

readConcern afterClusterTime value must not be greater than the current clusterTime

This error is typically a sign the application was written by calling advanceOperationTime() or using afterClusterTime as a read concern option directly without also calling advanceClusterTime() explicitly.

Is this issue urgent?

Causal consistency was introduced in MongoDB 3.6 and the client session API has not been substantially changed since then. More recently there are internal teams which are using causal consistency to solve limitations (e.g. SERVER-53813 and reading from the primary, or safely reading from nearest member / secondaries) and so any urgency would come from a perceived increase usage if there's any urgency at all.

Is this ticket required by a downstream team?

Both App Services and Mongosync would benefit from changes to the Golang driver.

Is this ticket only for tests?

This ticket has functional impact.

Acceptance Criteria

It must be possible in a single function call on each client session to run an operation in client session B causally after an operation in client session A. For client sessions from the same MongoClient, this is already possible with the existing client session API:

session_a = client.start_session()
session_b = client.start_session()
session_b.advance_operation_time(session_a.operation_time)
# No need to do session_b.advance_cluster_time(session_a.cluster_time) because the MongoClient
# already gossips the highest $clusterTime seen across all client sessions.

However the same automatic highest $clusterTime gossiping is not also true for client sessions from different MongoClients. Both App Services and Mongosync use multiple MongoClients which connect to the same MongoDB Cluster within the same process.