The FindCmd currently acquires an AutoGetCollectionForReadCommand early in its code path:

https://github.com/mongodb/mongo/blob/a8bf9e88b3cd2c0036b3ae3e484dbbc933fc4614/src/mongo/db/commands/find_cmd.cpp#L359-L362

This is held while constructing the PlanExecutor via getExecutorFind(), and it continues to be held while actually running the PlanExecutor to produce the first batch of results. Since getExecutorFind() may invoke runtime planning mechanism to choose a plan, query execution may occur both when calling this method and when constructing the first batch.

This lock must be held for the classic query execution engine, as it uses the kLockExternally model. This means that the caller is responsible for acquiring the necessary locks. SBE, on the other hand, uses the kLocksInternally model. It acquires its own locks as needed. The fact that the FindCmd also holds the lock is problematic for yielding, since the SBE yielding code has no means to relinquish this lock. As a result, not all locks held by the query are released during a yield unless that yield is happening during a getMore. This means that when the system is configured to use SBE, an operation requiring a strong lock on the collection could block for a long time behind a find command.

I discovered this while attempting to adapt commands_handle_kill.js to run a test case with SBE enabled. Doing so would be a good way to test that this ticket has been addressed adequately.