Summary

The snapshot session specification states that drivers should store the atClusterTime value in a private field, but there are many instances where an application may want to set/access the value.

Motivation

Who is the affected end user?

Users of a driver that would like to take advantage of snapshot reads.

How does this affect the end user?

There are a few snapshot sessions usages that are not possible to do today given the current limitation. e.g.

1. Perform a snapshot read and then start a changestream from the snapshot's timestamp.
2. Perform a snapshot read in one thread, and then perform another read in a separate thread using the same snapshot timestamp.
3. Perform a write and then perform a snapshot read using the operation time of the write.

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

Main path? Edge case?

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

Minor annoyance at a log message? Performance concern? Outage/unavailability? Failover can't complete?

Is this issue urgent?

Does this ticket have a required timeline? What is it?

Is this ticket required by a downstream team?

It is required for Device Sync. In the meantime, we had to expose this field in our fork of the go driver: https://github.com/mongodb-forks/mongo-go-driver/commit/5cd00b584fc0e0019f20822274214110b2f55ab2

Is this ticket only for tests?

No

Acceptance Criteria

1. Ability to set the snapshot timestamp for a session
2. Ability to retrieve the snapshot timestamp from a session