A (albeit unlikely) crash could occur in the following scenario

• A resharding recipient is in kCreatingCollection, receives an abort after creating the collection
• The recipient cleans up the temporary collection (which means the collection gets renamed to a drop-pending collection, keeping the same UUID) but steps down before it can persist its transition to kDone
• The recipient steps back up, still in kCreatingCollection
• Before the coordinator re-sends _shardsvrAbortReshardCollection to the new primary, the recipient state machine begins to run again
• ensureTempReshardingCollectionExistsWithIndexes will then cause an invariant to be hit since the drop-pending renamed temporary collection with the ReshardingUUID is still in the catalog