multi_statement_transaction_all_commands_same_session FSM workload may start transactions with the same session id on multiple clients. The purpose is to add test coverage for session checkout. However, SERVER-37179 makes waiting for read concern only depend on user's input and beginOrContinue() a transaction after waiting for read concern. As a result, starting transactions on the same session of a running transaction will check out the session and go through the read concern code path, which may need to acquire the global IX lock to access the oplog. If a dropDatabase's global X lock request has been enqueued after the running transaction's global IX lock. The global IX lock request for oplog will be blocked. Even worse, since the session has been checked out, the original client who started the currently running transaction cannot make progress either.

This won't be a problem in production, because 1) normal drivers won't restart a transaction and clients all use their own sessions; and 2) it's already a known issue that catalog operations require strong locks, blocking any new operations, so transaction timeout, 60 seconds by default, is designed for this known issue. concurrency_simultaneous_replication test suite changed the transaction timeout to 3 hours because 1 minute isn't sufficient for slow machines to commit transactions.

To solve the problem in testing, we blacklisted multi_statement_transaction_all_commands_same_session.js in concurrency_simultaneous_replication as part of SERVER-37179. PM-1242 will use finer-grained locks for catalog changes. After that, we can unblacklist the workload.