Rollback via refetch goes through four steps before the node can return to the replica set as a functioning secondary:

1. Enter rollback state
2. Perform writes for rollback
3. Apply oplog window determined via the node that was being fetched from
4. Leave rollback state

All writes done while a node is in rollback state must be persisted before a node can persist a write that implies rollback has completed. This is the repl-storage rollback via refetch contract.

Rolling back a dropIndexes command will recreate the index via the secondary code path.

This will hit the code path that creates an IndexBuilder.

When the IndexBuilder completes an index, it has to decide how the catalog write will be timestamped, potentially timestamping the write itself via the time on the LogicalClock.

In the case of rollback, requiresGhostCommitTimestamp can return true. Additionally, there's no guarantee the LogicalClock time will be such that the write is persisted before the write that implies rollback is complete (the repl-storage rollback via refetch contract) . It's possible for the ready: true write to be too far in the future and not persisted on a restart. A restart would see an unfinished index and may drop it, which would result in an inconsistency with the rest of the replica set.