collection_catalog_two_phase_drops.js tries to make sure the two phases of the drop are executed as expected, that is, it first checks the drop of the table is deferred, then forcing an oplog write and a fsync (which triggers a checkpoint) to check the ident were finally dropped.

The second phase of a local drop collection is actually performed by the tiemstamp monitor, which means, that in order to actually drop a table, the snapshot history window must have passed, so, considering the advancement of the latest stable timestamp is done by the journal flusher which is an asynchronous thread, it is possible that the checkpoint triggered by fsync fails to persist the timestamp of the oplog write, making the second phase of the drop to never occur.

This is a test issue, in production, the checkpoint thread (which is paused by the test) will eventually find the latest timestamp advanced by the journal flusher, successfully executing the second phase of the drop. We should ensure the oplog write was persisted before triggering a checkpoint.