drop and other commands that work on views follow this pattern:

1. Lock the namespace requested in the command.
2. If it is a view, also lock system.views.

If (1) is done via the Shard Role API (acquireCollectionOrView), it will acquire a snapshot and stash a catalog.

However since system.views is locked later, that snapshot & catalog may not reflect the latest state of system.views.

Unless this is manually found out and worked around, this causes race conditions where the in-memory view catalog goes out of sync with the on disk system.views. For example:

• Op1 locks view1 (X) using the Shard Role API, which acquires an snapshot & catalog.
• Before Op1 locks system.views (X), a concurrent Op2 locks it and creates view2.
• Op1 lock system.views (X).
• Op1 calls dropView("view1").
• As part of the drop, the CollectionCatalog reloads system.views from disk.
• Since the views are reloaded from an stale snapshot, this overwrites the in-memory views so the view catalog no longer contains view2.
• Now the in-memory view catalog and the on-disk system.views are out of sync.

If locking a view in X mode, the Shard Role API should implicitly lock system.views so that this kind of race condition is not possible.

(Note that it's possible to lock system.views through the Shard Role API, however operations like drop don't necessarily act over a view so they don't know beforehand if they should acquire system.views.)