The change in SERVER-25175 intended to fix a problem with initial sync as it interacts with its sync source to procure a list of indexes for each collection to build. If a background index build is in progress on the sync source and the sync source is a primary node, the background index build may or may not complete successfully. (Some examples of how it could fail are: 1. the node steps down 2. the background index build is interrupted by a killOp command 3. the background index build discovers some collection data that violates a constraint on the index being built, if the index spec has constraints.) The initial syncing node will proceed to attempt to build this same index, which might complete successfully even if the index build on the primary does not. This could leave the initial syncing node with an index that no other node has.

The initial sync process uses the listIndexes command on the sync source to obtain lists of indexes per collection. The attempt to fix this problem changed the listIndexes command to not report in-progress index builds (this will only affect background index builds, as foreground index builds lock the collection for their entirety and thus can never be observed in-progress by the listIndexes command). The fix had the intended effect for initial sync sync sources that are in primary state, but it also unintentionally changed the behavior of initial sync sync sources that are in secondary state. For such sources, background index builds are destined to complete successfully (since they already have done so on a primary node), and therefore cannot fail. Such index builds also write their oplog entries prior to completion, and therefore the only indication that an initial syncing node has to build the index is the listIndexes command response. Hiding in-progress index builds from initial sync for sync sources that are in secondary state could result in missing indexes for the initial sync. This code change restores the old behavior where listIndexes shows in-progress index builds.