During an index rebuild, IndexBuildsManager::startBuildingIndexForRecovery will go back to the beginning in the case of a write conflict exception in a partial batch. This can lead to "infinite looping" behaviour for some classes of cursor problems (see HELP-40283).

It should do something that makes failures a bit clearer, e.g. having a retry limit if the occasional write conflict is expected, or possibly aborting the build for that index.

This issue can occur when data corruption is present such that keys returned from the storage engine are not in ascending order.

Update
When an out-of-order key is detected, we will no longer throw a WriteConflictException when performing a collection scan. The DataCorruptionDetected error will be thrown instead. For v6.3 and up a new health log entry will be inserted into the local.system.healthlog collection that includes both keys, namespace, ident, scan direction and a stack trace.