Summary

Allow “general causality”: cache the client’s highest-seen operationTime—as currently happens for clusterTime—and optionally send it in readConcern.afterClusterTime. This will make causal consistency much easier by providing it without a session.

Consider enabling general causality by default for unsharded clusters when readPref==primary since there will never be additional latency.

Motivation

Causal consistency is:

• needed for safe use of MongoDB in many cases
• off by default—and thus frequently omitted errantly
• sometimes easy to misuse. The Go driver in particular types the session-context the same as a non-session context, which makes it very easy to use the wrong context, which subtly breaks causal consistency.

Who is the affected end user?

Most MongoDB users.

How does this affect the end user?

They don’t know they need causal consistency & so have subtle bugs, which can include corruption.

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

It’s quite likely that a given application lacks causal consistency somewhere that it’s actually needed.

It’s “fairly rare” for that causal consistency to be necessary for durability … but definitely not “never”.

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

A client does a write then a read, doesn’t see the write, misreports stale state to some other part of the system, and that stale state gets persisted. Now we have 2 out-of-sync persisted states, which is internal corruption.

Is this issue urgent?

Not urgent.

Is this ticket required by a downstream team?

Not required.

Is this ticket only for tests?

No, this is for production.

Acceptance Criteria

The spec should outline a “general causality” mode that, when enabled, sends afterClusterTime wherever appropriate to ensure causal consistency with the most recently-received server response.