When running in Master-Slave mode, the replication "commit point" never advances, since there is no consensus protocol used in this mode. For replication recovery and rollback purposes, in the ReplicationCoordinator we maintain a list of "stableTimestampCandidates" which is updated with a new timestamp every time we update our lastApplied optime. The current "stable" timestamp is calculated as the largest timestamp in this list less than the commit point. We will remove timestamps from this list when they are less than the current stable timestamp. If we add timestamps to this list, but the commit point never advances, then the stableTimestampCandidates list will grow unbounded. This can cause performance issues as this list grows and we keep trying to insert things to it every time an operation comes in. This was causing a test to timeout when we insert a few hundred thousand documents (see linked BF).

To fix this, we should check if we are running in master slave mode and refrain from updating the stable timestamp list if so.