In renameCollection, we obtain the db lock in X mode. Then, we assert that there are no in-progress index builds. However, according to the logs in the linked BF, an index build was in-progress while we were running renameCollection. In the index build code path, it seems that we don't always hold on to collection and DB level locks. Specifically, while we are waiting for a next action, we assert that we are not holding any locks. As a result, it seems possible for the following sequence to occur:

1. A node starts initial sync
2. Index build starts
3. Index build releases collection/db level locks while waiting for next action but before committing
4. renameCollection command begins and obtains DB lock
5. renameCollection tries to assert that there are no index builds in progress, finds that there are, and aborts in progress index builds

It seems the initial sync node managed to complete initial sync successfully, even after the index build was aborted. I filed SERVER-55008 to resolve that issue on the Replication side. Open question for Execution: is the above situation considered a bug in the system? If not, I think we can resolve this by not running the JS test while nodes are going through initial sync.