This ticket is for the replication team to tighten-up the guarantees of the protocol and API for trailing on-disk state and is to serve as a placeholder and dependency for the recent views related bugs. The description below captures my conversation with lingzhi.deng@mongodb.com and suganthi.mani@mongodb.com.

The current API of onInitialDataAvailable/isDataRecovering is adequate for the near term, but it has a problem very specific to the views catalog since it is tightly coupled with collections. Namely, in the case of FCBIS, the views catalog is loaded from the last consistent (stable) snapshot, but due to the member state of the node at that point, isDataRecovering is still true. This causes the views catalog to not be kept in sync during oplog replay and so the namespaces it contains diverge from the available collections, causing false namespace conflicts.

This ticket is about decouplig isDataRecovering from the member state and making it becomes true immediately after rollback to stable, which will cover both FCBIS and replication rollback.

The changes will also cover the RS_REMOVED state and that will solve SERVER-89272.

Once this work is done, we can recommit the views fixes.

As part of this work we discussed giving better names to the methods to match their meanings more accurately:

• onInitialDataAvailable -> resetInMemoryState
• isDataRecoving -> isInMemoryStateInSync