The CSRS is registering a topology time tick point (timestamp X)when observing local inserts and applyOps modifying config.shards. On majority commit, if the timestamp of the majority committed oplog entry is greater or equal than X, the topology time is then advanced to X.

The current implementation does not take into account rollbacks and may end up bumping wrongly the topology time. Example:

• A shard entry is added to config.shards at time T
• A tick point is registered with timestamp T
• Rollback happens, oplog gets truncated to the operation registered at T-2
• A new CSRS primary steps up, the shard is added at time T-1 and then any write happens at time T
• On majority commit, the old primary ticks the topology time to T instead of T-1