In fcbis_restart_node_during_sync_with_pre_images.js, the intended order of events is:

• start an FCBIS on a secondary
  • secondary opens a backup cursor
• shutdown and restart the secondary
  • which will call _killBackupCursor
    • which will send a fireAndForget command
      • that might fail, accidentally leaking a backup cursor
  • restart the secondary
    • which will also call _killBackupCursor at the start of initial sync
      • which will be insufficient, because the secondary is not aware of the leaked backup cursor from the previous run
  • hang the secondary once it hits this "fCBISHangAfterDeletingOldStorageFiles" failpoint
• restart the entire replica set to ensure that any leaked backup cursors are killed
• continue initial sync process

We need to kill any leaked backup cursor because _openBackupCursor will fail if there is an existing backup cursor: the sync source does not allow two backup cursors to exist simultaneously; the old one must be killed

• However, what actually happens is:
  • FileCopyBasedInitialSyncer::_startInitialSyncAttempt calls
    • FileCopyBasedInitialSyncer::_startSyncingFiles which calls
      • FileCopyBasedInitialSyncer::_cloneFromSyncSourceCursor which calls
        • FileCopyBasedInitialSyncer::_openBackupCursorWithRetry (which opens the backup cursor)
    • and only then does _startInitialSyncAttempt call FileCopyBasedInitialSyncer::_prepareStorageDirectoriesForMovingPhase

• which hangs the "fCBISHangAfterDeletingOldStorageFiles" failpoint

As a result, if we leak a cursor, we will unfortunately still try to open a backup cursor before we hit the failpoint, and hit the duplicate-cursor-error crash-loop we were trying to avoid.

So, we need to answer:

• what work actually needs to be done on the secondary before we restart the set (i.e. would it be problematic to instead wait for an earlier failpoint that occurs before we attempt to make a new backup cursor?)
• how can we guarantee that that work is done without opening a backup cursor in the process