Two-phase dropDatabase may not replicate all collection drops before the database drop.

The first phase of dropDatabase (for replicate sets) in 3.6 is to individually drop each collection (drop in this first phase is a misnomer for rename). When those "drops" are majority confirmed, the primary replicates a dropDatabase oplog entry.

However the loop uses an iterator over the _collections map and db->dropCollectionEvenIfSystem will perform a rename. This rename erases the entry followed by adding it back under a different name. The expectation of the for-each collection loop is that all collections will be observed. The erase/add of the underlying map breaks that requirement.

This can result in some collections not being dropped on the primary nor the secondary in the first part of dropping a database. I do believe the second phase of dropping a database that's associated with the dropDatabase oplog entry will be renamed and/or dropped on both the primary and secondary.

One possible fix is to copy the values from the map to iterate over instead.