SERVER-104888 recently modified the commit sequence of from.renameCollection(target), requiring the placement change of the renamed collection to be persisted on config.placementHistory before the rest of the metadata get committed on the global catalog through a single transaction.

The fact that the two steps are no longer atomic breaks a fundamental assumption of the resetPlacementHistorycommand, which may now be executed between them: when this happens, the  reset deletes the most recent placement about target (because it has been already majority committed), but it does not recompute a new entry (because there is no routing table for the namespace yet).