This only applies to development versions of 4.0 that allow chained replication where secondaries are running in a mode that allows readers while concurrently processing batches.

There are two mechanisms that publish a new oplog visibility timestamp on secondaries during steady state replication. The first is forcefully setting the read timestamp to the end of a batch after it is applied. The second is a background thread that queries WT for the "all committed" time and publishes it as the new read visibility.

Secondary oplog application works in two phases. The first phase writes a batch of documents to the oplog asynchronously. This has the impact of causing the "all committed" time to jump around as opposed to only incrementing, which is what oplog visibility expects. Without a concurrent reader, this is fine, a reader can only come in when those oplog holes become plugged.

As a last detail, I heard it was expected for secondary oplog readers to use the "last applied" time to cap oplog visibility, which would be correct AFAIK. However, if _isOplogReader is set, the oplog visibility timestamp gets priority over the last applied.