Sharding metadata commands often take collection distributed locks. Drop collection on a sharded collection takes distlocks. Concurrency suites cannot / do not handle the LockBusy errors that can arise due to concurrent metadata commands, drop collection being more popular than the other metadata commands in our current concurrency tests.

view_catalog_cycle_with_drop.js is a frequently failing workload. kill_aggregation.js (kill_rooted_or.js) failed, too, and drop_collection.js workload.

Concurrency workloads should not be running drop collection commands. Drop collection during set up between concurrency tests is fine – no concurrency --, but not in the workloads themselves.

UPDATE:

Rather than removing drop collection from concurrency workloads, make LockBusy on drop collection/database commands retryable in the concurrency suites. See the comments for similar cases we've handled in the JS.