The authoritative shards metadata recovery process has to navigate a lot of race conditions successfully.

One of these involves the way it waits until it's safe to read at a given timestamp. As explained in this comment the recoverer has to do the following series of steps in a deliberate order:

1. Install the recoverer so that it tracks oplog entries arriving after its installation
2. Wait until a timestamp at or after the recoverer was installed is snapshot readable
3. Read at that snapshot
4. Drain the oplog entries and install the metadata

A potential source of sudden delays involves the wait for the timestamp to become available.

In principle with this approach the only possible timestamp usable for the recoverer is the lastWritten timestamp since it's the top-most timestamp on the node with no other writes more recent than it. However, in order to support the snapshot read that timestamp has to become majority available, and this can take a prolonged amount of time under unfavourable conditions.