As part of SPM-3810 "Improve error reporting and handling between WiredTiger and Server") we added an invariant for uncommitted data encountered during a drop table call. We shouldn't encounter this behaviour, and with the added functionality that SPM-3810 provides we are able to invariant on this. Running a patch build triggered an invariant failure here, and further investigation into the stack trace showed a possible bug in dropping tables with multi document transactions. This could potentially be due to the fact that it takes time for WiredTiger to commit the transaction to disk so we are running into this as WiredTiger is still committing. 

Inserting on a non existent collection in a multi document transaction triggers an implicit creation of the collection and index that only the transaction is aware of. On rollback and corresponding drop we shouldn't encounter uncommitted data since the collection is only internally visible to the transaction.

In this scenario, if we find ourselves in a situation where we need to drop the collection and we somehow fail to do so, we will not actually end up dropping the table until we restart. This is because we call dropIdent to do so and dropIdent circumvents adding the table to the drop pending reaper , instead it just directly calls drop so if the call to drop fails we just don't end up removing it as the call intentionally ignores failures.