The find command (and presumably any other command that needs to resolve UUIDs to namespaces), can return a NamespaceNotFound error on a collection that is concurrently renamed within the same database. If we try to execute a find command by UUID for a collection that exists but is being concurrently renamed, there is a race condition due to the fact that the find command resolves UUIDs to namespaces outside of its locks. For example, consider the following execution for a find and renameCollection command running on separate threads:

Although accesses to the UUIDCatalog are made atomic by the catalog lock, different commands may still interleave their operations on the catalog in an arbitrary order, if not protected by stronger (database or collection level) locks.

Attached is a repro (find_by_uuid_and_rename.js) demonstrating this issue. The race condition appears to be very narrow. Its probability is increased by adding a short sleep immediately after this line. Adding a mongo::sleepmillis(50) seemed sufficient.