In the following scenario taken from the description of the linked BF, a drop database command can return that the operation was completed successfully when the database was actually not dropped. The drop database command should check the version of the existing coordinator to ensure that it is not joining the coordinator for a different database.

1. the test creates unsharded collection "test.coll"
2. mongos sends a _shardsvrDropDatabase to the primary shard s0:n0
3. s0:n0 start a drop database coordinator dropDBcor_1
4. s0:n0 drop "test.coll"
5. s0:n0 manage to drop the database "test" (by removing the db entry in the config.databases) but the coordinator (dropDBcor_1) is still running.
6. s0:n0 steps down and s0:n1 became the new primary of shard 0
7. mongos receives an InterruptedDueToReplStateChange on the original _shardsvrDropDatabase command
8. mongos retries the dropDatabase command but find out that the database have been already dropped. So it will simply return OK to the client
9. mongos creates new database and collection "test.coll" while the old coordinator (dropDBcor_1) is still running.
10. mongos attempts to drop the database "test" for the second time by sending a _shardsvrDropDatabase to s0:n1 and since dropDBcor_1 is still running it will join it. The problem is that `dropDBcor_1` is already at a late stage of the execution (running the cleanup phase) and it won't drop again the database.