afterClusterTime

Parent: Causal Consistency · Published reference · snapshot 2026-10-15

Depth-first rabbithole dossier for afterClusterTime; source-anchored research pack.

These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.

How it works

[low] The `afterClusterTime` field must be sent when executing causally consistent operations on deployments that support cluster times, but must not be sent on deployments that do not support cluster times. Sources: https://raw.githubusercontent.com/mongodb/specifications/master/source/causal-consistency/causal-consistency.md [source]
[low] The first read in a causally consistent session must not send `afterClusterTime` to the server because the `operationTime` has not yet been determined. Sources: https://raw.githubusercontent.com/mongodb/specifications/master/source/causal-consistency/causal-consistency.md [source]

Problems, failure modes and limitations

[low] You cannot specify `atClusterTime` together with `afterClusterTime`. Sources: https://www.mongodb.com/docs/manual/reference/read-concern.md [source]
[low] An error indicating `afterClusterTime` is greater than `clusterTime` typically signifies the application called `advanceOperationTime()` or used `afterClusterTime` directly without explicitly calling `advanceClusterTime()`. Sources: https://jira.mongodb.org/browse/DRIVERS-2860 [source]
[low] If a client sends `afterClusterTime` to a new primary that has not advanced its cluster time, it receives an error stating that `readConcern afterClusterTime` must not be greater than the `clusterTime` value. Sources: https://jira.mongodb.org/browse/SERVER-30977 [source]

Comparisons and alternatives

[low] Instead of returning an error when `afterClusterTime` exceeds the current cluster time, the new primary should perform a no-op write to advance its cluster time. Sources: https://jira.mongodb.org/browse/SERVER-30977 [source]

Facts and statements

[low] For read operations in causally consistent sessions, drivers automatically set the `afterClusterTime` read concern option, which is unset for read operations not associated with such sessions. Sources: https://www.mongodb.com/docs/manual/reference/read-concern.md [source]
[low] To satisfy a read request with an `afterClusterTime` value of `T`, a `mongod` must perform the request after its oplog reaches time `T`, waiting to service the request if the oplog has not yet reached that time. Sources: https://www.mongodb.com/docs/manual/reference/read-concern.md [source]
[low] The `afterClusterTime` field can only be set if the read concern level is `majority`, `local`, or `snapshot`. Sources: https://jira.mongodb.org/browse/DRIVERS-2369 [source]
[low] The `operationTime` must be stored in the `ClientSession` to be passed as the `afterClusterTime` field of the `readConcern` in subsequent causally consistent read and write operations. Sources: https://raw.githubusercontent.com/mongodb/specifications/master/source/causal-consistency/causal-consistency.md [source]
[low] Commands run using `runCommand` must not have an `afterClusterTime` field added to them. Sources: https://raw.githubusercontent.com/mongodb/specifications/master/source/causal-consistency/causal-consistency.md [source]
[low] As of 2026-05-04, `afterClusterTime` is required on all write commands in causally-consistent sessions, not only on read commands. (verified as of 2026-10-15) Sources: https://raw.githubusercontent.com/mongodb/specifications/master/source/causal-consistency/causal-consistency.md [source]
[low] The length of time (in milliseconds) a secondary waits if `afterClusterTime` is greater than the last applied time from the oplog is defined by `waitForSecondaryBeforeNoopWriteMS`. Sources: https://www.mongodb.com/docs/manual/reference/parameters.md [source]
[low] After `waitForSecondaryBeforeNoopWriteMS` passes, if `afterClusterTime` is still greater than the last applied time, the secondary makes a no-op write to advance the last applied time. Sources: https://www.mongodb.com/docs/manual/reference/parameters.md [source]
[low] A retried read sends a read concern document that includes `afterClusterTime`. Sources: https://jira.mongodb.org/browse/DRIVERS-2369 [source]
[low] If causal consistency is disabled in implicit sessions, retried reads will not send `readConcern.afterClusterTime`. Sources: https://jira.mongodb.org/browse/DRIVERS-2369 [source]
[low] Do not manually set `afterClusterTime` for a read operation. Sources: https://www.mongodb.com/docs/manual/reference/read-concern.md [source]
[low] The `afterClusterTime` value must not be greater than the current `clusterTime`. Sources: https://jira.mongodb.org/browse/DRIVERS-2860 [source]

Children

No children recorded.

← the whole tree · 3D view· how to read this page