Currently 2-phase index build for empty collection does the following steps.

1) We reserve an oplog slot with timestamp say TS(10), and write the "startIndexBuild" oplog entry with that timestamp.
2) We reserve another oplog slot with timestamp say TS(11) and use that to write commitIndexBuild oplog entry. To be noted, As a result of this step, all future writes done to that WT recovery unit will use timestamp TS(11).
3) Now, we start the index build which would update the catalog table to write the index entry with "ready" field as false using commitIndexBuild oplog entry's timestamp (TS(11)).
4) On Index completion/success, we would again update the catalog table to write the index entry with "ready" field as true using commitIndexBuild oplog entry's timestamp (TS(11)).

 Now, suppose if my stable timestamp/ checkpoint timestamp is TS(10) (i.e, startIndexBuild oplog entry), then it would miss rebuilding the index while replaying the commitIndex oplog entry during rollback and startup recovery. Because, when the node tries to replay the "commitIndexBuild" oplog entry during rollback/startup recovery, commitIndexBuild Oplog entry will fail with ErrorCodes::NoSuchKey since it won't be able to find any corresponding running/in-progress index. Also, when commitIndexBuild oplog entry fails with ErrorCodes::NoSuchKey, we don't escalate it to the caller (oplog applier), instead we suppress it as "ErrorCodes:NoSuchKey" is an acceptable error code during oplog application.