Speculative majority change streams that do an update lookup query will wait for the most recent lastApplied optime of a replica set node to majority commit before returning results to the client. This is intended to provide a guarantee to the client that the data it received is majority committed. This contract may be violated, however, in the case where a node's lastApplied optime lags behind the optime of the newest "storage committed" oplog entry. That is, there may be an oplog entry (and corresponding data operation) written to storage that is visible to readers, but the lastApplied optime of the node does not yet reflect it. This is possible because a primary node advances its lastApplied optime inside the onCommit handler of an operation's transaction. There is a nonzero length of time between the commit of the WriteUnitOfWork at the storage layer and when the optime is advanced for that operation. If a concurrent reader reads the effects of such a transaction and reads lastApplied before the onCommit handler has fired, it may wait for the incorrect optime to commit and return data that is not, in fact, majority committed. This is an issue for primaries. On secondaries lastApplied is only updated at the end of batch application, so the same problem does not manifest.