ChunkVersion consists of: <epoch, majorVersion, minorVersion>. The epoch is an ObjectId, which poses a problem for using it directly in the CatalogCache, because it is not comparable.

In order to make it comparable, we will need to utilise the configOpTime as a way to discern which epoch is the most recent one. As a context, when we go against the config server to retrieve the changed chunks, we use an {afterOpTime: <configOpTime>} as a way to ensure causal consistency with any previous writes. The response itself comes with the latest committed/visible opTime on the config server.

The proposal is to introduce a new class called say ComparableChunkVersion, which incorporates the latest visible opTime at the time a given ChunkVersion was obtained from the config server and in the case there is difference between the epochs, use the visibleOpTime as a tie-breaker to decide which epoch to use.

Due to the time at which the committed/visible opTime is attached to the response by the config server, it is possible that two ComparableChunkVersions contain different epochs E1 and E2, but the same visibleOpTime, in which case we can’t use a tie-breaker. In this case, the router will have to do a write against the config server in order to bump the visible opTime and redo the read.